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OPTIMIZED ROUTING BETWEEN COMMUNICATION NETWORKS 

5 FIELD AND BACKGROUND OF THE INVENTION 

The present invention relates to a system and method for 
routing messages and/or set of messages and/or sessions, in 
particular E.164 messages and/or set of messages and/or 

10 sessions (E.164 represents the international phone numbering 
system), to another network or operator. The other network is 
called foreign network, and the other operator foreign 
operator. In an E.164 message/session, the party/equipment 
originating the message/session indicates the E.164 number of 

15 the party/equipment to which the message/session is to be 
established. 

A problem arises in routing messages and/or set of messages 
and/or sessions such as E.164 messages and/or set of messages 
20 and/or sessions to a foreign operator when one or more of the 
following three conditions are true concerning the foreign 
network and operator: 

CI) The foreign operator uses the same number range for 
IMS (IMS = IP Multimedia Subsystem) and non-IMS e.g. CS 
25 (Circuit Switched) networks; 

C2) Only individual - not all - customers of the foreign 
operator have subscribed both the non-IMS and IMS; 

C3) The foreign operator does not allow to use its ENUM- 
DNS database (DNS = Domain Name System, ENUM is specified in 
30 RFC 2916 "E.164 number and DNS" ) via DNS delegation or as a 
copy for a trusted operator. 

The task of the ENUM- DNS database is to give answer whether 
the target identifier, i.e. the E.164 number, is a valid IMS 
35 identity and if yes, give one or more NAPTR. There is not 
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always a correct answer when E.164 belongs to the number 
range if non-IMS (e.g. GSM) and IMS number ranges overlap. In 
more detail, the ENUM-DNS database is used to answer the 
question Ql "Is the target E.164 a valid IMS identity?" of S- 
5 CSCF (S-CSCF = Serving Call State Control Function) in the 

originating message and/or set of messages and/or session and 
to return one or more NAPTR (NAPTR = Naming Authority 
Pointer; RR of DNS; RR = Resource Record of DNS) if the 
answer is positive. With these NAPTR RRs the E.164 can be 
10 converted to a valid IMS routing address that is used to 

route the message and/or set of messages and/or session to 
the target network. 

As mentioned above, there is not always a correct answer to 
15 the question "Ql" above when E.164 belongs to the number 
range in condition "CI". 

ENUM-DNS then may return "not found", "domain unknown" or a 
similar result. This means that the E.164 number is not a 
20 valid IMS identity. 

However, it may be that the E.164 number is actually a valid 
IMS identity but that this information cannot be obtained 
from the available ENUM-DNS in the originating network (i.e. 
25 condition "C3" is true). It can e.g. be obtained only in the 
trusted networks or possibly only in the target network 
itself. The answer in these cases is that the E.164 number 
may be a valid IMS identity. 

30 According to the present IMS standard draft (3GPP TS 23.228 
V.5.0.0) the message/session is routed to an own BGCF, and 
from there to an own MGCF or to a BGCF in the target network 
that routes the message/session further to a MGCF in the 
target network. From MGCF the message/session is routed to 

35 non-IMS e.g. CS network. If the E.164 message/session is a 
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multimedia message/session that cannot be routed in non-IMS 
e.g. CS network, the message/session is released latest at 
MGCF in the own or in the target network. 

5 Reasons of this problem are as follows. The normal way would 
be to utilize the hierarchical structure of DNS databases. 
This evidently was the original idea but it was not accepted 
as such in the standardization i.e. there is no global ENUM- 
DNS. Some operators are even reluctant to let the other 
10 operators see their IMS subscriber database i.e. ENUM-DNS 
database. 

In the situation described above the "holes" in the ENUM-DNS 
database are non-IMS e.g. CS (CS = Circuit Switched) 
15 subscribers that have not yet become IMS subscribers. 

In addition operators seem to be unwilling to publish not 
even information of the amount of the subscribers they have. 
That information (ENUM database and number of IMS 
20 subscribers) can easily be seen from ENUM-DNS if it is 
publicly available in the situation described above. 

In such case, the message/session may be routed to an own 
BGCF (BGCF = Breakout Gateway Control Function) , and from 
25 there to an own MGCF (MGCF = Media Gateway Control Function) 
or to a BGCF in the target network that routes the 
message/session further to a MGCF in the target network. 

From MGCF the message/session is routed to non-IMS e.g. CS 
30 network. If the E.164 session is a voice session, this is 

appropriate, and the called party gets a voice session to his 
non-IMS terminal e.g. to GSM mobile station. 

If, however, the E.164 message/session is a multimedia 
35 message/session that cannot be routed in non-IMS e.g. GSM 
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network, the message/session is released latest at MGCF in 
the own or in the target network. 



According to one aspect, the invention provides a system as 
defined in the independent system claims or any one of the 
dependent system claims. 

10 

According to a further aspect, the invention provides a 
method as defined in the independent method claims or any one 
of the dependent method claims. 

15 The invention provides a solution for routing messages and/or 
set(s) of messages and/or sessions depending on checked 
message/session requirements, e.g. media and/or QoS and/or 
other requirements of the message or the set of messages or 
the requested session. 

20 

The invention with all its embodiments and/or variations 
and/or combinations can be applied to messages and/or to 
sessions and also to messagesets, which are sets of messages 
that do not establish a session. A messageset contains one or 

25 more messages each with possible response message (s) . An 

example of the messageset is the so called instant message 
that may carry multimedia content. Another example is the 
subscription of the presence information of another 
subscriber. The delivery of the presence information can be 

30 seen as part of the same messageset (especially if the 

delivery is done immediately and it utilizes the reverse 
route of the subscription) or it can be seen to build a 
separate messageset (especially when a change in the presence 
information is reported later or when the delivery is routed 

35 independently of the subscription) . 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a solution which will lead to an early release 
of IMS message and/or session; 

Fig. 2 illustrates an implementation where a message and/or 
messageset and/or session is always routed as a normal IMS 
message and/or session", 

Fig. 3 illustrates an embodiment of the present invention 
which provides a solution "Route the message and/or 
messageset and/or session according to the media and/or QoS 
and/or other requirements", 

Fig. 4 illustrates an embodiment of the present invention 
which provides a solution "Create an additional route from 
target i.e. terminating BGCF to I-CSCF", 

Fig. 5 illustrates an embodiment of the structure of utilized 
ENUM-DNS databases in accordance with an implementation of 
the present invention, 

Fig. 6 shows utilized ENUM-DNS databases used at an 
originating BGCF, 

Fig. 7 shows utilized ENUM-DNS databases used at a 
terminating BGCF, 

Fig. 8 illustrates an implementation for routing messages 
and/or messagesets and/or sessions which originate from IMS, 
wherein all E.164 messages and/or messagesets and/or sessions 
are routed via BGCF without ENUM query at originating S-CSCF, 
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Fig. 9 shows an implementation of the invention similar to 
the structure of Fig. 8, wherein all E.164 messages and/or 
messagesets and/or sessions are routed via BGCF without ENUM 
query at originating S-CSCF, 

5 

Fig. 10 shows an embodiment of the invention wherein a BGCF 
serves as transit exchange, 

Fig. 11 shows an embodiment which provides routing to a 
10 subscriber roaming in a legacy network, 

Fig. 12 shows embodiments for explaining routing examples for 
routing messages and/or messagesets and/or sessions such as 
calls from one to another equipment, 

15 

Fig. 13 shows an embodiment providing enhanced routing based 
on media and/or QoS and/or other requirements, 

Fig. 14 shows a further embodiment providing enhanced routing 
20 based on media and/or QoS and/or other requirements, and 

Fig. 15 illustrates another embodiment of the present 
invention which provides a solution "Route the message and/or 
messageset and/or session according to the media and/or QoS 
25 and/or other requirements" - 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE 

INVENTION 

30 

Below, several solutions are proposed relating to the routing 
of message and/or messageset and/or session using E.164 
number as identifier for identifying the terminal/subscriber 
to which the message and/or messageset and/or session is to 
35 established. 
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A basic solution includes the introduction of a routing chain 
S-CSCF - BGCF(o) - BGCF(t) - I-CSCF (o=originating; 
t=terminating) . Local ENUM-DNS is used at an own originating 
S-CSCF to decide whether the E.164 is an IMS identity or not. 
A subset of the local ENUM-DNS database containing only the 
own IMS E.164 identities can be used also at an own 
terminating BGCF to make the same decision when accepting the 
terminating routing from terminating BGCF to I-CSCF. 

A different ENUM-DNS database may be provided for routing at 
BGCF to an own MGCF or to a foreign i.e. terminating BGCF. So 
the following three ENUM-DNS databases are provided to manage 
all E.164 routing including special routing from terminating 
BGCF to I-CSCF: 1) ENUM-DNS database of own IMS E.164 
identities; 2) ENUM-DNS database of IMS E.164 identities of 
the trusted operators (a part of these may be delegations to 
appropriate ENUM-DNS databases of respective operators 
following standard DNS principles); 3) ENUM-DNS database to 
find FQDN of the own MGCFs and foreign BGCFs (i.e. BGCFs of 
other operators/networks) . 

Some possible solutions SI) to S5) for handling messages 
and/or messagesets and/or sessions, in particular IMS 
25 messages and/or messagesets and/or sessions, to be routed to 
another network, are disclosed and discussed in the 
following. 

51) Release the message and/or messageset and/or session 
30 earlier, possibly already at the originating S-CSCF, 

52) Route the message and/or messageset and/or session 
always as a normal IMS message and/or messageset and/or 
session, 

35 
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53) Route the message and/or messageset and/or session 
according to the media and/or QoS and/or other requirements, 

54) Create an additional route from target i.e. 
5 terminating BGCF to I-CSCF, 

55) Use only one contact point type in the network. 

The solution SI, "Release the message and/or messageset 
10 and/or session earlier", includes the following steps: 

Check media and/or QoS and/or other requirements of the 
message /message set /session; 

if non-IMS e.g. CS network cannot route the 
15 message/messageset/session, release the 
message/messageset /session . 

Checking could be done as early as in the originating S-CSCF, 
latest it should be done in the originating BGCF or MGCF. 

20 This solution will lead to an early release of IMS messages 
and/or messagesets and/or sessions but will not support the 
routing of such messages and/or messagesets and/or sessions 
to the intended party/equipment. 

25 Fig. 1 illustrates this solution SI). In the case shown in 
Fig. 1, a subscriber A 1 is attached to a visited network 3 
which includes a P-CSCF 2. Network 5 is the home network of 
A, and includes a S-CSCF 4, a Local ENUM-DNS database 6, a 
MGCF 8, and a BGCF 9. Further, network 10 represents the home 

30 network of the called party/entity B 17. The network 10 

includes a BGCF 11, an I-CSCF 12, a HSS 13, a S-CSCF 14, a P- 
CSCF 15, and a MGCF 16. 

A Circuit-Switched (CS) network 18 is also available for 
35 handling connections. 
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The above and below description of the network 
elements/entities shown in Fig. 1 and their interrelationship 
is valid and applicable also for the further drawings unless 
5 otherwise described below. 

In the following, the steps shown in Fig. 1 are described: 

1) A message or session request message, e.g. SIP INVITE 
10 message, indicating the E.164 number of a called party B, 

e.g. +358-50-22112233 which may be E.164 of Radiolinja's IMS 
subscriber, is sent from user equipment A to P-CSCF 2 of the 
visited network 3 visited by (e.g. roaming) subscriber A. 

15 2) The P-CSCF 2 of the visited network 3 sends the 

message/session request message, e.g. INVITE message, to the 
S-CSCF 4 of A subscriber's home network 5, indicating the 
E.164 number of the called party, +358-50-22112233. 



20 3) The S-CSCF 4 of the home network 5 performs a local IMS 
ENUM-DNS 6 query indicating the E.164 number. When assuming 
that the local ENUM-DNS database 6 does not contain the 
called IMS subscriber, there will be, in this case, an 
"unknown domain", "not found" or alike response or no 

25 response at all from ENUM-DNS database 6. 

4) The message/messageset/session is then released, or routed 
further from S-CSCF 4 to the BGCF 9 in the home network 5 
where it is released. The message/messageset/session is 
30 released if the media, QoS or other requirement cannot be 
fulfilled in the non-IMS e.g. CS network carrying 
message/messageset/session to the target network. Checking 
requirements and releasing the message/messageset/session 
already in S-CSCF 4 avoids routing to MGCF 8 in vain. 
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The solution S2, "Route the message and/or messageset and/or 
session always as a normal IMS message and/or messageset 
and/or session", is illustrated in Fig. 2, and includes the 
following steps: 

5 

Route all messages and/or messagesets and/or sessions 
from the originating S-CSCF 4 to the target I-CSCF 12 (I-CSCF 
= Interrogating Call State Control Function) of the network 
10. The target operator of network 10 handles the 

10 message/messageset/ session. If the 

message/messageset/session is a valid IMS 
message/messageset/session, it is routed normally as IMS 
message/messageset/session. If the message/messageset/session 
is not a valid IMS message/messageset/session, it is routed 

15 from I-CSCF 12 via BGCF 11 to MGCF 16, and possibly via non- 
IMS e.g. CS network 18, to entity 17. Thus, the routing is 
proper. 

If the message and/or messageset and/or session is not a 
20 valid IMS message/messageset/session: the target operator may 
alternatively release the message/messageset/session and the 
originating operator of network 5 can reroute the 
message/messageset/session via an own BGCF 9. 

25 This solution creates a new routing to route messages and/or 
messagesets and/or sessions from I-CSCF 12 via BGCF 11 to 
MGCF 16. In this case, the target operator has to handle a 
terminating non-IMS e.g. CS message/messageset/session at I- 
CSCF 12. An additional S-CSCF, e.g. a default S-CSCF for non- 
30 IMS subscribers, or alike can be used between I-CSCF 12 and 
BGCF 11. 

Fig. 2 illustrates an example of an information flow 
according to solution S2. In this example, a HSS query (HSS = 
35 Home Subscriber Server), step 5, is involved, as shown in 
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Fig. 2. 

In the following, the steps shown in Fig. 2 are described: 

5 1) A message or session request message, e.g. SIP INVITE 

message, indicating the E.164 number of a called party, e.g. 
+358-50-55223344 which may be E.164 of Radiolinja's non-IMS 
subscriber, is sent from user equipment A to P-CSCF 2 of the 
visited network 3 visited by (e.g. roaming) subscriber A. 

10 

2) The P-CSCF 2 of the visited network 3 sends a 
message/session request message, e.g. INVITE message, to the 
S-CSCF 4 of A subscriber's home network 5, indicating the 
E.164 number of the called party, +358-50-55223344. 

15 

3) The S-CSCF 4 of the home network 5 performs a local IMS 
ENUM-DNS query indicating the E.164 number. When assuming 
that the local ENUM-DNS database 6 does not contain the 
called subscriber, there will be, in this case, an "unknown 

20 domain", "not found" or alike response or no response at all 
from ENUM-DNS database 6 because the identity is a non-IMS 
identity. 

4) The message/messageset/session is then routed further from 
25 S-CSCF 4 to the I-CSCF 12 in the home network 10 of 

subscriber B. The address of the I-CSCF 12 is fetched from 
routing database, which may be e.g. a routing table or an 
ENUM-DNS database specialized for routing similarly as the 
ENUM-DNS database 7 in Fig. 3. 

30 

5) The I-CSCF 12 performs a HSS 13 query using the E.164 
number. The HSS 13 returns information that the E.164 is not 
an IMS identity. HSS 13 may return the address of BGCF 11 of 
the home network 10 of subscriber B. If a S-CSCF, e.g. for 

35 non-IMS subscribers, is used between I-CSCF 12 and BGCF 11, 

11 
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HSS may return its address. 

6.) The message/messageset /session is then routed to the BGCF 
11. 

5 

7) A message/session request, e.g. INVITE message is sent 
from BGCF 11 to MGCF 16 of network 10 of B, indicating the 
identity of B. 

10 8) The MGCF 16 routes the message/messageset/session to CS 
network 18 which carries the message/messageset or 
establishes a session to Subscriber B (step 9) . 

One of the preferred solutions in accordance with embodiments 
15 of the invention is the solution S3) . 

An embodiment in accordance with the solution S3, "Route the 
message and/or messageset and/or session according to the 
media and/or QoS and/or other requirements", is shown in Fig. 
20 3, and includes the following steps. 

Check the media and/or QoS and/or other requirements of 
the messsage and/or messageset and/or session; 

if non-IMS e.g. CS network could not route the 
25 message/messageset/session, the message/messageset/session 
has to be an IMS message/messageset/session and should be 
routed as such. 

This checking is performed preferably in the home network 5 
30 of A. The check can be done as early as in the originating S- 
CSCF 4, latest it should be done in BGCF 9. 

An evaluation of the solution S3 shows that it is of 
advantage because multimedia IMS messages and/or messagesets 
35 and/or sessions are routed correctly to the target network. 

12 



WO 2004/008786 



T/IB2002/002782 



Non multimedia, e.g. voice, messages and/or messagesets 
and/or sessions are routed to the called party via non-IMS 
e.g. CS network. 

5 Checking media and/or QoS and/or other requirements is all 
that is needed. 

Fig. 3 illustrates an example of an information flow 
according to solution S3. In this example, two local ENUM-DNS 

10 database 6, 7 are provided. The local ENUM-DNS database 6 
preferably is a ENUM-DNS database containing IMS E.164 
identities of subscribers to which the network 5 is the home 
network. The database 6 may also correspond to the local 
ENUM-DNS database 6 of Fig. 2, and may include the same or 

15 essentially the same content as the latter. 

The local ENUM-DNS database 6 may include also IMS E.164 
identities of the trusted operators. This part of the 
database may contain delegations to appropriate ENUM-DNS 

20 databases of respective operators following standard DNS 
principles. The database 7 includes an ENUM-DNS database 
containing information to find FQDN (FQDN - Fully Qualified 
Domain Name) of foreign I-CSCFs (i.e. I-CSCFs of other 
operators/networks) . Instead of the database 6 other means 

25 may be used to help translating E.164 to corresponding 

routing address. Instead of the database 7 other means, e.g. 
routing tables, may be used to find address of foreign I- 
CSCFs. 

30 A HSS query (HSS = Home Subscriber Server) , step 6, is also 
involved, as shown in Fig. 3. 

Fig. 3 illustrates an example of an information flow 
according to solution S3. 

35 
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In the following, the steps shown in Fig. 3 are described: 

1) A message or session request message, e.g. SIP INVITE 
message, indicating the E.164 number of a called party, e.g. 

5 +358-50-22112233 which may be E.164 of Radiolinja's IMS 

subscriber, is sent from user equipment A to P-CSCF 2 of the 
visited network 3 visited by (e.g. roaming) subscriber A. 

2) The P-CSCF 2 of the visited network 3 sends a message or 
10 session request message, e.g. INVITE message, to the S-CSCF 4 

of A subscriber's home network 5, indicating the E.164 number 
of the called party, +358-50-22112233. 

3) The S-CSCF 4 of the home network 5 performs a local IMS 
15 ENUM-DNS query to the local ENUM-DNS database 6, indicating 

the E.164 number. When assuming that the local ENUM-DNS 
database 6 does not contain the called IMS subscribers, there 
will be, in this case, an "unknown domain", "not found" or 
alike response or no response at all from ENUM-DNS database 
20 6. 

3 ■ ) Because no NAPTR resource records were received from 
ENUM-DNS database 6, the IMS identity is considered non-IMS 
identity. That is why the originating S-CSCF 4 checks the 

25 media requirements and/or QoS requirements and/or other 

requirements of the message/messageset/session by checking 
the information contained in the request received from P-CSCF 
2 in order to decide whether the message/messageset/session 
can be routed through non-IMS (e.g. CS) network or whether it 

30 should be routed via IMS network. 

4) When the message/messageset/session has to be routed via 
IMS network, the E.164 is regarded as an IMS identity. In 
order to route to the I-CSCF 12 the address of the I-CSCF 12 

35 is needed. That is why the S-CSCF 4 of the home network 5 
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performs a local IMS ENUM-DNS query to the local ENUM-DNS 
database 7, indicating the E.164 number. Routing address to 
I-CSCF 12 is built with the help of NAPTR RRs received from 
the local ENUM-DNS database 7. 

5 

5) When the check of step 3') indicates that the 
message/messageset/session cannot be routed through non-IMS 
network, the message/messageset/session is then routed 
further from S-CSCF 4 to the I-CSGF 12 in the home network 10 

10 of subscriber B. 

6) The I-CSCF 12 performs a HSS 13 query using the E.164 
number. The HSS 13 returns the address of S-CSCF 14 of the 
home network 10 of subscriber B. 

15 

7.) The message/messageset/session is then routed to the 
indicated S-CSCF 14. 

8) A message/session request, e.g. INVITE message is sent 
20 from S-CSCF 14 to P-CSCF 15 of network 10 of B, indicating 

IMS identity of B. 

9) The P-CSCF 15 routes the message/messageset/session to 
subscriber 17 so that the message/messageset is sent from A 

25 to B or session is established from A to B. 

When the check performed in step 3') of Fig. 3 should 
indicate that the message/messageset/session need not to be 
routed via IMS network, the message/messageset/session may be 
30 routed via non-IMS network i.e. via BGCF 9, MGCF 8, and CS 
network 18/ to entity 17. 

Another one of the preferred solutions in accordance with 
embodiments of the invention is the solution S4) . 

35 
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Solution S4, "Create an additional route from target i.e. 
terminating BGCF to I-CSCF", includes the following steps. 

a) Create a new routing from the target i.e. terminating 
5 BGCF 11 to I-CSCF 12 (I-CSCF = Interrogating Call State 

Control Function) . 

b) If the E.164 is a valid IMS identity, route from BGCF 
11 to I-CSCF 12, 

10 c) otherwise route as usual to a MGCF 16 (or 8) . 

d) If BGCFs 9, 11 drop themselves out, the routing is a 
normal IMS routing. 

The routing is then: originating S-CSCF 4 — > (I-CSCF 12) > 
15 terminating S-CSCF 14. 

The ENUM-DNS database can be utilized in BGCF 9 and/or 11 in 
making decision whether the E.164 is a valid IMS identity. 

20 This solution S4 provides correct routing in all cases. An 
extra routing from BGCF 11 to I-CSCF 12 may be needed. 

Fig. 4 illustrates an example of an information flow 
according to solution S4. In this example, the following 
25 conditions are assumed: Using E.164, originating a message 
and/or messageset and/or session by subscriber A, A 
subscriber's home network 5 is Sonera's network. 

The embodiment of Fig. 4 provides three databases 21, 22, 23, 
30 for checking and finding IMS identities and FQDNs. 

The database 21 is provided for network 5 and includes the 
own IMS E.164 identities as well as the IMS E.164 identities 
of the trusted operators. This database 21 is used by S-CSCF 
35 4 of the network 5, for finding IMS identities of 
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parties/terminals being identified by their E.164 numbers, in 
the message and/or session request message of step 2. 

The database 22 is also provided for network 5 and includes 
5 the FQDNs of the own MGCFs, e.g. MGCF 8, and foreign BGCFs, 
e.g. BGCF 11. This database 22 is used by BGCF 9 of the 
network 5, for finding FQDNs used for routing to 
parties/terminals/networks/NEs (Network Elements) being 
identified by the E.164 numbers, in the message and/or 
10 session request message of step 4. 

The database 23 is provided for network 10 and includes the 
own IMS E.164 identities as well as the FQDNs of the own 
MGCFs, e.g. MGCF 16, and foreign BGCFs, e.g. BGCF 9. This 
15 database 23 is used by BGCF 11 of the network 10, for finding 
IMS identities or FQDNs used for routing to 
parties/terminals/networks/NEs (Network Elements) being 
identified by the E.164 numbers, in the message and/or 
session request message of step 6a. 

20 

Description of the steps shown in Fig. 4: 

1) A message or session request message, e.g. SIP INVITE 
message, indicating the E.164 number of a called party, e.g. 

25 +358-50-55223344 which is e.g. E.164 of Radiolinja's non-IMS 
subscriber, is sent to P-CSCF 2 of the visited network 3 
visited by (e.g. roaming) subscriber A. 

2) The P-CSCF 2 of the visited network sends a message or 

30 session request message, e.gl INVITE message, to the S-CSCF 4 
of A subscriber's home network 5 (assumed to be Sonera 1 s 
network), here with +358-50-55223344. 

3) The S-CSCF 4 of the home network 5 performs a local IMS 
35 ENUM-DNS query to database 21 with 
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4.4.3. 3.2. 2. 5. 5.0. 5. 8. 5.3. local_ims_enum . el 64 . ims * sonera . f i . 
When assuming that the local ENUM-DNS database 21 contains 
Radiolinja's IMS subscribers, there will be, in this case, an 
"unknown domain", "not found" or alike response or no 
5 response at all from ENUM-DNS database 21 because the 
identity is a non-IMS identity. 

4) The message/messageset/session is routed further from S- 
CSCF 4 to the BGCF 9 in the own network 5. 

10 

5) The BGCF 9 performs a local routing ENUM-DNS query to 
database 22, with 

4. 4. 3,3. 2. 2. 5. 5.0-5. 8. 5. 3. local_routing_enum. el64 . ims . sonera . 
fi. Local routing ENUM-DNS database 22 contains a NAPTR RR 
15 for each possible routing from BGCF 9. 

The response returned to BGCF 9 is NAPTR that is used to get 
a valid IMS routing address. The result would be e.g. 
bgcf . ims . radiolin j a . f i . 

20 

6a) The BGCF 9 of the home network 5 of A sends a message to 
BGCF 11 of the home network 10 of the called party or 
equipment B, e.g. INVITE with +358-50-55223344 and using 
bgcf.ims.radiolinja.fi as routing address. 

25 

6b) Alternatively, or additionally to step 6a), the BGCF 9 
may send a message to the MGCF 8 of the home network 5 of A. 

7) The BGCF 11 of network 10 of B performs an ENUM-DNS query 
30 to database 23, with 

4. 4. 3. 3. 2. 2. 5. 5. 0.5. 8. 5. 3. el 64. ims . radiolin j a . f i . ENUM-DNS 
database 23 contains one or more NAPTR RR for Radiolin j a' s 
IMS subscribers and one or more NAPTR for each possible 
routing from BGCF 11. 
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The response returned by database 23 to BGCF 11 is NAPTR that 
is used to get a valid IMS routing address. The result would 
be e.g. mgcf2.ims.radiolinja.fi because the identity is non- 
IMS identity. 

5 

8a) E.g. in case of a non-IMS message and/or messageset 
and/or session, a message or session request, e.g. INVITE 
message is sent from BGCF 11 to MGCF 16 of network 10 of B, 
indicating +358-50-55223344 and using mgcf2.ims.radiolinja.fi 
10 as routing address. 

9a) The MGCF 16 routes the message/messageset/session to CS 
network 18 which carries a message/messageset or establishes 
a session to terminal 17 of Subscriber B (step 10a)). 

15 

8b) As an alternative to step 8a) , preferably in case of 
an IMS message and/or messageset and/or session, a message or 
session request, e.g. INVITE message is sent to I-CSCF 12 of 
20 network 10 of B, indicating +358-50-55223344 and using 
icscf.ims.radiolinja.fi as routing address. 

9b) The I-CSCF 12 performs a HSS inquiry. The HSS 13 returns 
the address of S-CSCF 14 assigned to subscriber B. 

25 

10b) The I-CSCF 12 sends a message or session request, e.g. 
INVITE message, to the S-CSCF 14 indicated in the HSS 
response . 

30 lib) The S-CSCF 14 sends a message or session request, e.g. 
INVITE message, to the P-CSCF 15 assigned to subscriber B. 

12b) The P-CSCF 15 sends a message/messageset or establishes 
the session to subscriber B. 

35 
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Let us assume that Sonera (358-40) is the originating 
operator while Radiolinja (358-50) is the terminating 
operator. Radiolinja is a trusted operator of Sonera. 

5 Figs. 5 to 7 illustrate ENOM-DNS databases queries and 

response, as clearly shown and described in these drawings. 

Fig. 5 shows the structure of utilized ENUM-DNS databases 
forming part of database 21 used at the originating S-CSCF 4. 

10 

An example of the database "IMS E.164 identities of the 
trusted operators", which contains NAPTR RRs for Radiolinja' s 
IMS E.164 identities 

(358-50-22112233 and 358-50-22112244) is: 
15 $ORIGIN 2. 2. 0.5. 8. 5. 3. local_ims_enum.el64.ims.sonera.fi. 
3.3.2.2.1.1 IN NAPTR 100 10 "u" "sip+E2U" 
" ! (*.*$) ! sip: \l@ims. radiolinja. fi ! " 
4.4.2.2.1.1 IN NAPTR 100 10 "u" "sip+E2U" 
" ! (*.*$) !sip: \l@ims. radiolinja. f i ! " 

20 

An example of the database "own IMS E.164 identities", which 
contains NAPTR RRs for Sonera's own IMS E.164 identities: 
(358-40-55667788 and 358-40-55667799) : 

$0RIGIN 5.5.0.4.8.5.3. local_ims_enum. el64 . ims . sonera . f i . 
25 8.8.7.7.6.6 IN NAPTR 100 10 "u" "sip+E2U" 
" ! ( A . *$) ! sip: \l@ims. sonera. f i ! " 
9.9.7.7.6.6 IN NAPTR 100 10 "u" "sip+E20" 
" ! ( A . *$) ! sip: \l@ims. sonera. fi ! " 

30 

The databases are used to find out whether the E.164 is an 
IMS identity, and if it is, to get NAPTR to build a routable 
IMS identity. 

35 The databases of the "own IMS E.164 identities" and the "IMS 
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E.164 identities of the trusted operators" may be located 
under the same domain name like in the examples above 
(local_ims_enum.el64.ims.sonera.fi.) or under different 
domain names. In the first case normally one ENUM-DNS query 
5 is enough while in the second case both databases need an own 
query. 

Fig. 6 shows the utilized ENUM-DNS databases of database 22 
used at the originating BGCF 9. 

10 

An example of the database "FQDNs of the own MGCFs and 
foreign BGCFs", which contains NAPTR RRs for routing to 
Sonera's own MGCFs and Radiolinja's BGCF: 

(358-40-56xxxxxx to Sonera's MGCF1) : 
15 (358-40-4xxxxxxx to Sonera's MGCF2) : 

(358-50-xxxxxxxx to Radiolinja's BGCF): Bare prefix can be 
used because IMS E.164 messages/messagesets/sessions (i.e. 
+358-50-22xxxxxx) are already routed from the originating S- 
CSCF to Radiolinja's I-CSCF. 

20 

$0RIGIN 6.5.0.4.8.5.3. local_routing_enum. el64 . ims . sonera . f i . 

* IN NAPTR 100 10 "u" "sip+E2U" 

" ! ( A . *$) ! sip: \l@mgcf 1. ims. sonera. f i ! " 

$0RIGIN 4.0.4.8.5.3. local_routing_enum. el64 . ims . sonera . f i . 
25 * IN NAPTR 100 10 "u" "sip+E2U" 

! (".*$) ! sip :\l@mgcf 2. ims. sonera.fi!" 
$ORIGIN 0.5.8.5.3. local_routing_enum. el 64 . ims . sonera . f i . 

* IN NAPTR 100 10 "u" "sip+E2U" 

" ! ( /v .*$) ! sip: \l@bgcf .ims.radiolinja.fi! " 

30 

The database is used to find routing addresses. 

Fig. 7 shows the utilized ENUM-DNS databases of database 23 
used at the terminating BGCF 11. 

35 
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An example of the database "own IMS E.164 identities", which 
contains NAPTR RRs for Radiolinja' s IMS E.164 identities 
(358-50-22112233 and 358-50-22112244): 

5 $ORIGIN 2. 2.0. 5. 8. 5. 3. el64. ims.radiolinja.fi. 
3.3.2.2.1.1 IN NAPTR 100 10 "u" "sip+E2U" 
" ! . *$) ! sip: \l@ims. radiolinja. f i ! " 
4.4.2.2.1.1 IN NAPTR 100 10 "u" "sip+E2U" 
" ! *$) ! sip: \l@ims . radiolinja.fi ! " 

10 

The database is used to find out whether the E.164 is an IMS 
identity, and if it is, to get NAPTR to build a routable IMS 
identity. 

15 An example of the database "FQDNs of the own MGCFs and 

foreign BGCFs", which contains NAPTR RRs for routing to 

Radiolinja' s own MGCFs and Sonera's BGCF 

(358-50-23xxxxxx to Radiolinja's MGCF1) : 

(358-50-5xxxxxxx to Radiolinja's MGCF2) : 
20 (358-40-xxxxxxxx to Sonera's BGCF): Bare prefix can be used 

because IMS E.164 messages/messagesets/sessions (i.e. +358- 

40-55xxxxxx) are already routed from the originating S-CSCF 

to Sonera's I-CSCF. 

25 $0RIGIN 3. 2. 0.5. 8. 5. 3. el 64. ims . radiolin j a . f i . 

* IN NAPTR 100 10 "u" "sip+E2U" 

"! ( A .*$) ! sip: \l@mgcf 1 . ims. radiolinja.fi!" 
$0RIGIN 5. 0.5. 8. 5. 3. el64.ims.radiolinja.fi. 

* IN NAPTR 100 10 "u" "sip+E2U" 

30 "! (~.*$) !sip:\l@mgcf2.ims.radiolinja.fi! f ' 
$0RIGIN 0 . 4 . 8 . 5. 3 . el64 . ims . radiolinja . f i . 

* IN NAPTR 100 10 "u" "sip+E2U" 

"! (*.*$) ! sip: \l@bgcf .ims.sonera.fi! " 

35 The database is used to find routing addresses. 
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The databases of the "own IMS E.164 identities" and the 
"FQDNs of the own MGCFs and foreign BGCFs" may be located 
under the same domain name like in the examples above 
5 (el64.ims.radiolinja.fi.) or under different domain names. In 
the first case normally one ENUM-DNS query is enough while in 
the second case both databases need an own query. 

According to some of the embodiments of the invention, a 
10 terminating BGCF, e.g. BGCF 11, is able to route to I-CSCF. 

Further, some implementations describe how the ENUM databases 
are constructed and what kind of information they contain (3 
different types) . In another implementation of the invention, 
it is also possible to avoid the use of BGCFs. 

15 

In the following, further implementations of the invention 
will be described. 

According to some of the embodiments of the invention, Local 

20 ENUM-DNS is used at an own originating S-CSCF to decide 

whether the E.164 is an IMS identity or not. A subset of the 
local ENUM-DNS database containing only the own IMS E.164 
identities can be used also at an own terminating BGCF to 
make the same decision, provided that the terminating routing 

25 from terminating BGCF to I-CSCF is accepted. A different 

ENUM-DNS database is provided for routing at BGCF to an own 
MGCF or to a foreign i.e. terminating BGCF. Thus, only the 
following three ENUM-DNS databases are necessary to manage 
all E.164 routing including special routing from terminating 

30 BGCF to I-CSCF: 1) ENUM-DNS database of own IMS E.164 

identities; 2) ENUM-DNS database of IMS E.164 identities of 
the trusted operators. A part of this database may be 
delegations to appropriate ENUM-DNS databases of respective 
operators following standard DNS principles* 3) ENUM-DNS 

35 database to find FQDN of the own MGCFs and foreign BGCFs 
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(i.e. BGCFs of other operators/networks). 

Basically, for routing of E.164, BGCF was proposed to take 
care of the E.164 routing. However no clear means are 
5 standardized for the routing at BGCF. 

Routing from a terminating BGCF to I-CSCF is beneficial. If 
routing via several BGCFs is also allowed, the ENUM-DNS 
database used at the terminating BGCF may be the same as at 
10 the originating BGCF. 

The following is a short introduction to the local ENUM-DNS 
problem: ENUM-DNS used at the originating S-CSCF is local 
according to present published proposals. It means that it 

15 contains DNS NAPTR resource records (RR) only for the 

operator's own IMS subscribers and for the IMS subscribers of 
trusted operators. The trusted operators might e.g. be 
operators acting in the same country, partly owned operators 
or operators belonging to the same alliance. If the operator 

20 allows a non-IMS e.g. CS subscriber to keep the same E.164 
identity when he becomes an IMS subscriber, and all 
subscribers do not become IMS subscribers at the same time, 
the operator is obliged to have in the ENUM-DNS database in 
principle a NAPTR RR for every non-IMS e.g. CS subscriber 

25 that has become an IMS subscriber. The ENUM-DNS database 
evidently becomes a huge database. To copy such databases 
from one operator to another is not easy. Depending on the 
frequency the database is copied it may lack information of 
many new IMS subscribers. 

30 

The normal way to avoid copying would be to utilize the 
hierarchical structure of DNS databases. This way was not 
accepted in the standardization, because some operators are 
reluctant to let the other operators see their IMS subscriber 
35 database i.e. ENUM-DNS database. In the situation described 
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above the "holes" in the database are non-IMS e.g. CS 
subscribers that have not yet become IMS subscribers and thus 
would be potential target for competitors' marketing actions. 
In addition operators seem to be unwilling to publish not 
5 even information of the amount of the subscribers they have* 
That information (ENUM database and number of IMS 
subscribers) can easily be seen from ENUM-DNS if it is 
publicly available in the situation described above. 

10 Some of the advantages of the proposed solutions, in 

particular the solutions as shown in Figs. 4 to 7, are: 

a) Simple structure and functioning. 

b) Because no routing data is automatically exchanged between 
operators, there are no severe security problems like with 

15 TRIP (TRIP = A Framework for Telephony Routing over IP (RFC 
2871)) (if TRIP is used as automatic routing data exchange 
method between operators) . 

c) One simple routing method and tool for all E.164 routing. 

d) Operators do not need to reveal the content of their ENUM- 
20 DNS databases to other operators. 

e) Reuses the existing ENUM-DNS database in TS 23.228 to 
create a new routing feature from terminating BGCF to I-CSCF. 

f ) Valid method to route from originating BGCF to a foreign 
I-CSCF. 

25 g) BGCF can be used as a "transit exchange" for MGCFs/MSSs 

(i.e. MSC servers) or alike. Economical solution because BGCF 
drops itself out after the first message of the session or 
messageset is processed. 

h) Possible to utilize only a local routing database, which 
30 doesn't contain addresses of all BGCFs of all other networks 
but only addresses of BGCFs in the near located networks. 
This way the standalone message (s) and/or the first message 
of the session/messageset possibly hops through several BGCFs 
in several networks and records the correct route for 
35 subsequent messages. BGCF drops itself out from the route for 
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subsequent messages. 

Figs. 4 to 7 describe and show the relation of the different 
ENUM-DNS databases with a flow example. 

E.g. a regular expression field or other fields of NAPTR RR, 
or fields of SRV RR (SRV = a DNS RR for specifying the 
location of services (DNS SRV)) can be used to store 
attributes if needed. (SRV RRs are referred with the result 
of operation specified with NAPTR RR) . 

Both methods below can be utilized. 

In an implementation method 1: The same input file (e.g. the 
15 own IMS E.164 identities) is loaded two times to build DNS 
databases for two different zones/domains. 

Implementation method 2: Needed input files are 
appended/merged to build one input file that is used to build 
20 DNS database for a certain zone/domain. 

One of the main ideas of this implementation of the invention 
is to use a single method (i.e. ENUM-DNS) for all E.164 
routing by combining the existing ENUM-DNS database in TS 
25 23.228 with a new ENUM-DNS database to create a complete 

routing method for E.164. And to reuse the existing ENUM-DNS 
database in TS 23.228 to create a new routing feature: 
routing from terminating BGCF to I-CSCF. 

30 In accordance with some embodiments of the invention, two 
paths to a foreign network may be provided: the first path 
via I-CSCF and the second via BGCF. 

Fig. 8 shows an embodiment providing such two transmission 
35 paths. Home network 32 of subscriber A 30 contains a P-CSCF 
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31, a S-CSCF 33, and a BGCF 34. Home network 37 of subscriber 
B 42 contains a I-CSCF 36, a P-CSCF 41, a S-CSCF 39, a BGCF 
43, a HSS 40, and several MGCFs 44, 45, 46. 

5 An idea of the implementation of the invention in accordance 
with the embodiment shown in Fig. 8 is to route all E.164 
messages and/or messagesets and/or sessions via BGCF 34 and 
non-E.164 messages and/or messagesets and/or sessions via I- 
CSCF 36. 

10 

In the explaining texts of the Fig. 8 only call is mentioned 
as an example of message, messageset and session. 

In the embodiment of Fig. 8, all E.164 messages and/or 
15 messagesets and/or sessions are routed via BGCF without ENUM 
query at originating S-CSCF. 

According to this principle E.164 messages and/or messagesets 
and/or sessions are routed directly to an own BGCF 34 without 

20 ENUM- DNS query or any other analysis in S-CSCF 33. From the 
own BGCF 34 the message and/or messageset and/or session is 
routed to a BGCF 4 3 in the target network 37. That BGCF 4 3 
analyzes the E.164 and decides whether to route the message 
and/or messageset and/or session to I-CSCF 36 or to one of 

25 the own MGCFs 44 to 4 6 or possibly to a BGCF in another 

network. A routing database, which is obtained e.g. with TRIP 
protocol (TRIP = A Framework for Telephony Routing over IP 
(RFC 2871)), can be used as the basis for decisions where to 
route the messages and/or messagesets and/or sessions at BGCF 

30 4 3 as well as at BGCF 34. The routing database may also be 
e.g. a routing table or an ENUM- DNS database like databases 
23 and 22 of Fig 4. 

The routing with different identifiers (Logical name; IMS 
35 E.164 number; non-IMS E.164 number) identifying the 
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terminating, e.g. called entity is explained below, the step 
sequence being in accordance with the step numbering shown in 
Fig. 8. 

5 Fig. 8 deals with a case where messages and/or messagesets 
and/or sessions, e.g. calls originate from IMS. The messages 
and/or messagesets and/or sessions, e.g. calls originating 
from IMS may include logical name, IMS E.164 number, or non- 
IMS E.164 number, as an identifier for identifying the called 
10 party or terminal. 

Routing with logical name: 

As shown in Fig. 8, when A 30 is originating a message and/or 
messageset and/or session, a message including the logical 

15 name is sent to P-CSCF 31 (step 1) in the customary manner 
which transmits a message to S-CSCF 33 (step 2). S-CSCF 33 
detects that the message contains no E.164 number but the 
logical name, and gets FQDN of I-CSCF 36 from the logical 
name. The S-CSCF then routes the message/messageset /session 

20 to the I-CSCF 36 of network 37 (step 3a) . The I-CSCF 36 
performs a HSS 40 query (step 6) using the logical name 
received from the S-CSCF 33, and routes the 
message/messageset/session according to the information 
received from HSS 40, via S-CSCF 39 (step 7), P-CSCF 41 (step 

25 8) to the called party terminal/entity B 42 (step 9). 

Routing with IMS E.164: 

As shown in Fig. 8, when subscriber or entity A 30 is 
originating a message and/or messageset and/or session, a 

30 message including the E.164 number is sent to P-CSCF 31 (step 
1) in the customary manner which transmits a message (step 2) 
including this identifier to S-CSCF 33. S-CSCF 33 detects 
that the message contains E. 164 . number, and routes the 
message/messageset/session to BGCF 34 of own network 32 (step 

35 3b) • The BGCF 34 forwards the message/messageset/session, 
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e.g. call, to the BGCF 43 of network 37 (step 4). BGCF 43 
detects that the message contains IMS E. 164 . number, and 
routes the message/messageset/session to I-CSCF 36 (step 5a) . 
The I-CSCF 36 performs a HSS query using the IMS E.164 number 
5 received from the BGCF 43 (step 6) , and routes the 

message/messageset/session according to the information 
received from HSS, via S-CSCF 39 (step 7), P-CSCF 41 (step 8) 
to the called party terminal/entity B 42 (step 9) . 

10 Routing with non-IMS E.164: 

As shown in Fig. 8, when A 30 is originating a message and/or 
messageset and/or session, a message including the E.164 
number is sent to P-CSCF 31 (step 1) in the customary manner 
which transmits a message including this identifier to S-CSCF 

15 33 (step 2) . S-CSCF 33 detects that the message contains 

E. 164. number, and routes the message/messageset/session to 
BGCF 34 of own network 32 (step 3b) . The BGCF 34 forwards the 
message/messageset/session, e.g. call, to the BGCF 43 of 
network 37 (step 4). BGCF 43 detects that the message 

20 contains non-IMS E. 164 .number, and routes the 

message/messageset/session (step 5b) to one of the MGCFs 44, 
45, or 46. 

Fig. 9 shows an implementation of the invention similar to 
25 the structure shown in Fig. 8. The same reference numerals 
indicate the same components as in Fig. 8. Fig. 9 
additionally shows a non-IMS network e.g. PSTN 50 originating 
a message and/or messageset and/or session, e.g. call, a MGCF 
51, a HSS 52, and an I-CSCF 53, each provided in network 32. 

30 

In the embodiment of Fig. 9, similar to the embodiment of 
Fig. 8, all E.164 messages and/or messageset and/or sessions 
are routed via BGCF without ENUM query at originating S-CSCF. 

35 A routing database, which is obtained e.g. with TRIP protocol 
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(TRIP = A Framework for Telephony Routing over IP (RFC 
2871)), can be used as the basis for decisions where to route 
the messages and/or messagesets and/or sessions at BGCF 43 as 
well as at BGCF 34. The routing database may also be e.g. a 
5 routing table or an ENUM-DNS database like databases 23 and 
22 of Fig 4. 

As a first example, a case is considered where routing is 
required in subscriber's home network 32 to subscriber A 30 
10 as terminating terminal, with IMS E.164 number being 

indicated in the message and/or messageset and/or session 
initiating message sent from non-IMS network e.g. PTSN 50. 

As shown in Fig. 9, when a party or terminal of the non-IMS 
15 network e.g. PSTN 50 intends to initiate a message and/or 

messageset and/or session, e.g. originate a call, it sends a 
message (step 1) to the MGCF 51 which forwards the message to 
the BGCF 34 (step 2). The BGCF 34 detects from the received 
identifier, i.e. IMS E.164 number, which I-CSCF 53 is taking 
20 care, and forwards the message to the I-CSCF 53 (step 3a) . 
The I-CSCF 53 performs a HSS 52 query using the IMS E.164 
number (step 4), and receives information on the S-CSCF 33 to 
be used. The I-CSCF 53 addresses S-CSCF indicating the 
identifier (step 5) which forwards the message/session request 
25 via P-CSCF 31 (step 6) to the terminal A 30 (step 7) as a message 
or for establishing the session. 

In a second example, a case is considered where routing is 
required to another network 37 to terminal B 42 as a 
30 terminating terminal, with IMS E.164 number being indicated 
in the message and/or messageset and/or session initiating 
message sent from non-IMS network e.g. PTSN 50. 

As shown in Fig. 9, when a party or terminal of the non-IMS 
35 network e.g. PSTN 50 intends to initiate a message and/or 

30 



WO 2004/008786 




:T/IB2002/002782 



messageset and/or session, e.g. originate a call, it sends a 
message (step 1) to the MGCF 51 which forwards the message to 
the BGCF 34 (step 2) . The BGCF 34 detects from the received 
identifier, i.e. IMS E.164 number, that BGCF 43 of network 37 
5 is taking care of the number, and forwards the message to the 
BGCF 43 (step 3b) . The BGCF 43 detects from the received 
identifier, i.e. IMS E.164 number, which I-CSCF 36 of network 
37 is taking care of the number, and forwards the message to 
the I-CSCF 36 (step 8a) . The I-CSCF 36 performs a HSS 40 

10 query using the IMS E.164 number (step 9), and receives 
information on the S-CSCF 39 to be used. The I-CSCF 36 
addresses S-CSCF 39 indicating the identifier (step 10) which 
forwards the message/session request via P-CSCF 41 (step 11) 
to the terminal B 42 (step 12) as a message or for 

15 establishing the session. 

As a third example, a case is considered where routing is 
required to another network 37 and further to a terminal in a 
non-IMS network as a terminating terminal, with non-IMS E.164 
20 number being indicated in the message and/or messageset 

and/or session initiating message sent from non-IMS network 
e.g. PTSN 50. 

As shown in Fig. 9, when a party or terminal of the non-IMS 
25 network e.g. PSTN 50 intends to initiate a message and/or 

messageset and/or session, e.g. originate a call, it sends a 
message (step 1) to the MGCF 51 which forwards the message to 
the BGCF 34 (step 2). The BGCF 34 detects from the received 
identifier, i.e. non-IMS E.164 number, that BGCF 43 of 
30 network 37 is taking care of the number, and forwards the 
message to the BGCF 43 (step 3b). The BGCF 43 detects from 
the received identifier, i.e. non-IMS E.164 number, which 
MGCF 45 of network 37 is taking care of the number, and 
forwards the message to the MGCF 45 (step 8b). The MGCF 45 
35 executes the necessary steps for sending the 
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message/messageset to or establishing the session with the 
called party. 

A first problem solved by these and other implementations of 
5 the invention is the routing without ENUM-DNS. 

It is impossible to know before HSS query has been done 
whether E.164 is or is not an IMS number. ENUM-DNS is used as 
a method to solve this, problem. 

10 

However ENUM-DNS databases are huge databases. They are 
needed only to find out whether the E.164 is an IMS number 
(corresponding NAPTR resource record is found in ENUM-DNS) or 
not (corresponding NAPTR resource record is not found) . 

15 Building and administration of the ENUM-DNS database is a 
huge task. And it can be easily imagined that the global 
ENUM-DNS hierarchy will never become totally complete. It is 
questionable whether it is worth of the effort to build ENUM- 
DNS databases just to get the information whether the E.164 

20 is an IMS number or not. Routing with E.164 can easily be 

separated from the functionality of the CSCFs and handled in 
a specialized NE i.e. BGCFs. Hence it is possible to avoid 
the use of ENUM-DNS so as to solve the above problem. 

25 A second problem solved by these and other implementations of 
the invention is a situation when ENUM-DNS is not available 
at the moment, or not at all, or the needed part in the 
hierarchy of ENUM-DNS is not available at the moment or not 
at all (e.g. the access path to the ENUM-DNS database is 

30 congested, the database has crashed, too long delay, etc) . 

When ENUM-DNS information concerning the E.164 is not 
available, the message and/or messageset and/or session has 
to be routed from the originating S-CSCF to an own BGCF. The 
35 BGCF routes the message/messageset/session to a BGCF in the 
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target network. That BGCF has to route the 

message/messageset/session to I-CSCF if the E.164 is an IMS 
number, otherwise to MGCF. 

5 Fig. 10 shows an embodiment wherein the problem of "Transit 
exchange" is solved, A BGCF serves as transit exchange. 

Some operators like to have a network element (NE) that can 
- route traffic via IP network between non-IMS network 
10 elements, e.g. Mobile Switching Centers (MSCs) , IP trunks, 

MSC servers, connected to IMS network e.g. via MGCFs like in 
the Fig. 10. In this embodiment, a BGCF is provided for 
routing such traffic. 

15 A network 60 shown in Fig. 10 comprises a BGCF 61 serving as 
traffic exchange. The BGCF 61 is able to communicate with 
other network elements (I-CSCF 62, a plurality of MGCFs 64, 
etc) of the network 60 such as indicated by double-headed 
arrows. Thus, the BGCF 61 can work as a transit exchange 

20 between the network elements of network 60. Further, the BGCF 
is able to communicate with a BGCF 65 of network 66. Similar 
to the structure of network 60, the BGCF 65 of network 66 can 
communicate with other network elements (I-CSCF 67, a 
plurality of MGCFs 69, etc) of the network 66 such as 

25 indicated by double-headed arrows. Thus, the BGCF 65 can work 
as a transit exchange between the network elements of network 
66. The I-CSCFs 62, 67, are able to query HSSs 63, 68, resp., 
if necessary. Hence, the BGCF can be used as a transit 
exchange for solving the above problem. 

30 

The embodiment of Fig. 11 provides a solution to problems 
which may arise when a subscriber, in particular an IMS 
subscriber is roaming in a non-IMS e.g. legacy network. When, 
finding out after Location request to HSS, that a subscriber, 
35 e.g- IMS subscriber B 78, is roaming in a non-IMS e.g. legacy 
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network, e.g. network 74, the invention provides a 
possibility of how the message and/or messageset and/or 
session e.g. call is routed to the legacy network 74 from I- 
CSCF 71 of IMS network 70. 

5 

When a call or other type of message or messageset or session 
is to be routed to IMS subscriber B 78, the 

message/messageset/session e.g. a call is first routed to I- 
CSCF 71 of the home network 70 of subscriber B 78 (step 1) . 

10 After HSS 72 query (step 2), the I-CSCF 71 is informed that 
the called subscriber is presently roaming in non-IMS e.g. 
legacy network 74, and routes the message/messageset/session 
e.g. call to BGCF 73 of network 70 (step 3). The BGCF 73 
routes the message/messageset/session e.g. call to BGCF 75 of 

15 network 74 (step 4) or alternatively directly to MGCF 76 of 
network 74. The BGCF 75 forwards the 

message/messageset/session e.g. call to MGCF 76 of network 74 
(step 5) which routes the call to MSC 77 (step 6) and from 
there to the subscriber 78. Hence, routing from I-CSCF 71 to 
20 an own BGCF 7 3 solves the above problem. If a S-CSCF, e.g. 
for non-registered or roaming IMS subscribers, is used 
between I-CSCF 71 and BGCF 73, I-CSCF 71 routes to the S-CSCF 
and the S-CSCF routes to BGCF 73. 

25 Advantages of the above embodiments of the invention include: 
Clear routing: E.164 and logical names (e.g. 
john.smitheims.sonera.fi ) can have both their own separate 
routing path until the target network. Further, if I-CSCF on 
the border does not work messages and/or messagesets and/or 

30 sessions e.g. calls can be routed via BGCF and vice versa. 

In accordance with one of the preferred implementations of 
the invention, providing the possibility of using routing 
"via I-CSCF" and "via BGCF" as two alternative paths between 
35 networks, the implementation allows to route the messages 
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and/or messagesets and/or sessions e.g. calls from I-CSCF to 
BGCF and vice versa in order to change from one path to 
another. 

5 The implementations according to the invention may be used as 
a solution for example to transit exchange, and maybe also as 
a solution to roaming. 

These embodiments of the invention, e.g. as shown in Figs. 8 
10 to 11, allow to route E.164 and logical names separately and 
without any help of ENUM-DNS databases and allows routing 
between I-CSCF and BGCF (in the same network) to both 
directions. 

15 A routing database, which is obtained e.g. with TRIP protocol 
(TRIP = A Framework for Telephony Routing over IP (RFC 
2871)), can be used as the basis for decisions where to route 
the messages and/or messagesets and/or sessions at BGCF 65 
and 75 as well as at BGCF 61 and 73. The routing database may 

20 also be e.g. a routing table or an ENUM-DNS database like 
databases 23 and 22 of Fig 4. 

In accordance with some of the preferred embodiments of the 
invention, a new border element or functionality, let it be 

25 called DGCF i.e. Dividing Gateway Control Function, is 
provided which takes care of all incoming traffic from 
foreign IP multimedia networks. It divides the traffic to I- 
CSCFs and to BGCFs and may take care of the load sharing 
and/or balancing. It may handle the hiding i.e. 

30 encrypts/decrypts the name of the own S-CSCF if topology 
hiding is required. DGCF may contain address analysis e.g. 
digit analysis or query to local ENUM-DNS to decide the 
target network element. Different number ranges may be used 
for IMS and non-IMS subscribers to make it easy for DGCF to 

35 choose the routing to I-CSCF or to BGCF respectively. DGCF 
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may also contain firewall functionality because it is the 
contact point of the network. 

The introduction of BGCF increases the amount of contact 
5 points in the network, possibly doubles it. Because ENUM 

seems to remain local, at least in the beginning, there is no 
universal way to know whether the certain E.164 of a foreign 
network is an IMS number or not, i.e. should it be routed to 
I-CSCF or BGCF of the foreign network. Therefore the division 

10 is artificial and the result might be that all E.164 messages 
and/or messagesets and/or sessions e.g. calls are routed to a 
BGCF in the target network. That BGCF should check the E.164 
and decide whether it is an IMS number or not. That is one of 
the reasons why the separation of E.164 numbers of a foreign 

15 network cannot be done correctly in the originating network. 
If this separation is not done in the originating network, 
there is a problem where to route the message and/or 
messageset and/or session e.g. the call in the target 
network: to I-CSCF or to BGCF. Using DGCF in the target 

20 network this problem is solved. 

Fig. 12 illustrates an embodiment incorporating the new 
network element (s) DGCF. 

25 The embodiment of Fig. 12 illustrates some examples where a 
message and/or messageset and/or session request, e.g. a 
call, originating from a subscriber A 81 is directed to a 
subscriber B 96 which is presently roaming outside of its 
home network 86 in a visited network 94 which includes a P- 

30 CSCF 95. Home network 80 of subscriber A includes a P-CSCF 82 
receiving the message and/or session request from subscriber 
A (step 1) which forwards the message or session request to a 
S-CSCF 83 (step 2) . The S-CSCF 83 performs a query to a 
database (Local ENUM-DNS) 84 (steps 3, 4) in case E.164 is 

35 used as identity of B subscriber. 
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A routing database, e.g. routing table or ENUM-DNS, may be 
used to find routing address of DGCF when E.164 is used as 
identity. 

5 

The home network 86 of subscriber B includes one or more 
DGCFs 85, 92. Further, the network 86 includes customary 
components such as I-CSCF 87, BGCF 88, HSS 89, S-CSCF 90, and 
MGCF 91. 

10 

The other networks may also incorporate one or more DGCFs. 

Fig. 12 shows some routing examples for routing message 
and/or messageset and/or session such as calls from 
15 subscribers A to B. 

In a first routing example, the message and/or messageset 
and/or session request from A indicates E.164 number of the 
called party subscriber B which E.164 number is not an IMS 
20 number. The following steps are performed wherein the step 

numbers correspond to the numbers shown at the arrows of Fig. 
12. Steps 3 and 4 may be omitted and utilize only a routing 
database to route the messages and/or messagesets and/or 
sessions to own I-CSCFs and foreign DGCFs. 

25 

1. A message and/or session initiation request, e.g. INVITE 
request, is sent from A to P-CSCF 82, indicating the E.164 
identifier +358-40-1223344 of B 

2. The message or session initiation request, e.g. INVITE, is 
30 forwarded from P-CSCF 82 to S-CSCF 83 with +358-40-1223344. 

3. S-CSCF 83 conducts Local ENUM/DNS query to database 84 
with e.g. 4 . 4 . 3 . 3 . 2 . 2 . 1 . 0 . 4 . 8 . 5 . 3 . el64 . arpa . or 

4. 4. 3. 3. 2. 2. 1.0. 4. 8. 5. 3. el64.ims.europolitan.se. depending on 
what the operator uses as root for ENUM-DNS. 
35 4. "Unknown domain", "not found" or alike response or no 
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response at all is received because database 84 does not 
contain an entry for this identifier. 

5. Therefore, the message/messageset/session e.g. the call is 
routed further to the DGCF 85 in the target network 86 
5 indicated by "+358-40" . The message or session initiation 
request, e.g. INVITE, with +358-40-1223344 is sent from S- 
CSCF 83 to DGCF 85. 

6b. DGCF 85 sends the message/session request e.g. INVITE 
further to BGCF 88. 
10 7b. The BGCF 88 forwards the message/session request with 
+358-40-1223344 to MGCF 91. 

8b. The MGCF 91 sends the message or session initiation 
request or a setup request with +358-40-1223344 to non-IMS 
network e.g. PSTN 93. 

15 

Another possible routing could be from DGCF 85 to I-CSCF 87 
(step 6a) instead of to BGCF 88 (step 6b) . After HSS query 
from I-CSCF 87 to HSS 89 (steps 7a, 8a) , the message or 
session initiation request may be forwarded to BGCF 88. 

20 

In a second routing example, the message and/or messageset 
and/or session request from subscriber A indicates non-E.164 
IMS identifier of the called party subscriber B. The 
following steps are performed wherein the step numbers 
25 correspond to the numbers shown at the arrows of Fig. 12. 

1. A message and/or session initiation request, e.g. INVITE 
request, is sent from A to P-CSCF 82, indicating non-E.164 
IMS identifier, e.g. john.smith@ims.sonera.fi. 
30 2. The message or session initiation request, e.g. INVITE, is 
forwarded from P-CSCF 82 to S-CSCF 83 with the IMS identifier 
j ohn . smith@ims . sonera . f i . 

3-4. No ENUM-DNS query is needed because the identity is not 
an E.164 identifier. 
35 5. ims.sonera.fi is an address of DGCF 85 to which the 
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message or session request is sent* 

6a, DGCF 85 sends the message or session initiation request 
(e.g. INVITE) further to I-CSCF 87. 

7a. The I-CSCF 87 performs a Location request with the name 
5 identifier john. smith or i ohn . smithQims . sonera . fx or alike. 

8a. The HSS 89 returns the FQDN, e.g. scscfl2.ims.sonera.fi, 

of S-CSCF 90 where the B-subscriber is registered. 

9a. The I-CSCF 87 sends the message or session setup request, 

e.g. INVITE request, to scscfl2.ims.sonera.fi. 
10 10a. The S-CSCF 90 may send the message or session setup 

request directly to the P-CSCF 95. In the present embodiment, 

the network uses topology hiding and DGCF offers that service 

too. Therefore, the message or session setup request, e.g. 

INVITE, is sent to DGCF 92 for hiding purpose. 
15 DGCF 92 encrypts the name of S-CSCF 90 and adds its own name 

to the message to be used as contact point by P-CSCF 95. 

11a. DGCF 92 sends the message or session setup request, e.g. 

INVITE, to the address e.g. pcscf3.ims.radiolinja.fi of P- 

CSCF 95 of visited network 94. 
20 12a. The P-CSCF 95 sends the message or session setup 

request, e.g. INVITE request, to the user equipment 96 of B. 

In a third routing example, the message and/or messageset 
and/or session request from A indicates E.164 number of the 

25 called subscriber B which E.164 number is an IMS number. The 
following steps are performed wherein the step numbers 
correspond to the numbers shown at the arrows of Fig. 12. 
Steps 3 and 4 may be omitted and utilize only a routing 
database to route the messages and/or messagesets and/or 

30 sessions to own I-CSCFs and foreign DGCFs. 

1. A message and/or session initiation request, e.g. INVITE 
request, is sent from A to P-CSCF 82, indicating the E.164 
identifier +358-40-1223344 of B. 
35 2. The message or session initiation request, e.g. INVITE, is 
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forwarded from P-CSCF 82 to S-CSCF 83 with +358-40-1223344. 

3. S-CSCF 83 conducts Local ENUM-DNS query to database 84 
with e.g. 4.4.3.3.2.2.1.0.4.8.5.3.el64.arpa. or 

4. 4. 3. 3. 2. 2. 1.0. 4. 8. 5. 3. el64. ims . europolitan . se . depending on 
what the operator uses as root for ENUM-DNS. 

4. "Unknown domain", "not found" or alike response or no 
response at all is received because database 84 does not 
contain an entry for this identifier. 

5. Therefore, the message/messageset/session e.g. the call is 
routed further to the DGCF 85 in the target network 8 6 
indicated by "+358-40". The message or session initiation 
request, e.g. INVITE, with +358-40-1223344 is sent from S- 
CSCF 83 to DGCF 85. 

6b. DGCF 85 sends the message or session initiation request 
(e.g. INVITE) further to BGCF 88. BGCF 88 finds out that the 
E.164 number is an IMS number. 

7c. The BGCF 88 therefore forwards the message/session 
request with +358-40-1223344 to I-CSCF 87. 
7a. The I-CSCF 87 performs a Location request with the 
identifier E.164. 

8a. The HSS 89 returns the FQDN, e.g. scscfl2.ims.sonera.fi, 

of S-CSCF 90 where the B-subscriber is registered. 

9a. The I-CSCF 87 sends the message or session setup request, 

e.g. INVITE request, to scscfl2.ims.sonera.fi. 

10a. The S-CSCF 90 may send the message or session setup 

request directly to the P-CSCF 95. In the present embodiment, 

the network uses topology hiding. Therefore, the message or 

session setup request, e.g. INVITE, is sent to DGCF 92 for 

hiding purpose. 

DGCF 92 encrypts the name of S-CSCF 90 and adds its own name 
to the message to be used as contact point by P-CSCF 95. 
11a. DGCF 92 sends the message or session setup request, e.g. 
INVITE, to the address e.g. pcscf3.ims.radiolinja.fi of P- 
CSCF 95 of visited network 94. 

12a. The P-CSCF 95 sends the message or session setup 
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request, e.g. INVITE request, to the user equipment 96 of B. 

Another possible routing could be step 6a instead of steps 6b 
and 7c based e.g. on separate number spaces, or on local 
5 ENUM-DNS query. 

Advantages of the disclosed preferred embodiments of the 
invention are: 

a) If the operator uses DGCF, it avoids offering ENUM service 
10 concerning the own E.164 numbers to other operators, because 

all incoming calls are received by one element i.e. DGCF 
independently whether the E.164 is an IMS number or not. 

b) Load sharing/balancing between I-CSCFs and between BGCFs 
is done controlled in the own network, not with e.g. round 

15 robin via DNS queries from foreign networks. 

c) Security aspects (e.g. network topology hiding) and 
firewall are centralized into one element/functionality type 
i.e. into DGCF instead of into two element /functionality 
types i.e. into I-CSCF and BGCF. 

20 d) Fewer contact points in the network. 

e) Routing database (e.g. TRIP) for routing between BGCFs in 
different networks is not needed. 

Routing from BGCF to I-CSCF may be provided in case DGCF 
25 routes all messages/messagesets/sessions with E.164 to BGCF. 

DGCF may divide the traffic by checking the called party 
address and sending messages/messagesets/sessions with non- 
E.164 address to I-CSCF and others to BGCF. BGCF routes those 
30 calls further to I-CSCF that cannot be routed to MGCF. 

DGCF may divide the traffic between I-CSCF and BGCF also by 
checking media and/or QoS and/or other requirements. DGCF 
routes to BGCF only the traffic that can be routed further to 
35 non-IMS e.g. CS network via MGCF. 
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The DGCF functionality can be included in the same element 
with other functionalities e.g. with I-CSCF and/or BGCF or 
built as a separate NE (Network Element) . 

5 

According to this embodiment, only one kind of contact point 
is necessary in the network (DGCF type) . Formerly, two types 
of contact points (I-CSCF and BGCF) had to be provided. 

10 One of the ideas of this embodiment of the invention is thus 
to use only one contact point type in the network and 
therefore eliminate the need for separation of the routing in 
the originating network into two groups: IMS addresses (to I- 
CSCF) and non IMS addresses (to BGCF). This way ENuM is not 

15 needed, neither routing database at BGCF, obtained e.g. with 
TRIP, containing routing addresses of BGCFs in foreign 
networks . 

As mentioned above, because ENUM- DNS is a local database one 
20 cannot be sure whether a certain E.164 number is an IMS 

identity or not if the ENUM-DNS does not give any answer. In 
the following embodiment of the invention shown in Fig. 13, 
this decision is made in BGCF 106 based on the media 
requirements and/or QoS (i.e. Quality of Service) 
25 requirements and/or other requirements. From the media and/or 
QoS and/or other requirements the embodiment deduces whether 
the message and/or messageset and/or session should be routed 
via IMS network 113 or whether the routing via non-IMS e.g. 
CS network 118 is sufficient. In the first case no breakout 
30 is done to non-IMS e.g. CS domain, i.e. the message and/or 
messageset and/or session is routed to an I-CSCF 111 of a 
target network 113. 

In the second case the message and/or messageset and/or 
35 session is routed to a BGCF 110 of the target network 113 or 
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to a MGCF 107 of the own network 105 . 

In the following, a routing example based on media and/or QoS 
and/or other requirements is described. 

5 

The message and/or messageset and/or session is originated by 
indicating E.164 number of the called party terminal B 116. 
The originating message and/or messageset and/or session is 
originating from subscriber A 100, and A subscriber's home 
10 network 105 is in this example Swedish network Europolitan 
(Europolitan Vodafone) . 

The following steps are performed wherein the step numbers 
correspond to the numbers shown at the arrows of Fig. 13. 

15 

1. A message or session initiation request, e.g. INVITE 
request, is sent from A to P-CSCF 101 of visited network 102 
visited by subscriber terminal A 100, indicating the E.164 
identifier +358-40-1223344 of B 116. 
20 2. The message or session initiation request, e.g. INVITE, is 
forwarded from P-CSCF 101 to S-CSCF 103 of A' s home network 
105, indicating the identifier +358-40-1223344. 

3. S-CSCF 103 conducts Local ENUM-DNS query to database 104 
with 4. 4. 3. 3. 2. 2. 1.0. 4. 8. 5. 3. el 64. ims . europolitan . se . 

25 "Unknown domain", "not found" or alike response or no 

response at all is received in step 3 because database 104 
does not contain an entry for this identifier. 

4. Therefore, the message/messageset/session e.g. call is 
routed further to the BGCF 106 in the own home network 105 

30 where media and/or QoS and/or other requirements are checked, 
and the message and/or messageset and/or session is routed 
further depending on the checked requirements so as to comply 
with the media and/or QoS and/or other requirements 
accordingly. 

35 5a, 5b, 5c. Depending on the result of the media and/or QoS 
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and/or other requirements check by BGCF 106, step 5a, 5b, or 
5c is performed. 

5a. Because the message/messageset/session has to be an IMS 
5 message/messageset/session according to the checked 

requirements it is routed through IMS network. The message or 
session setup request, e.g. INVITE message, is sent from BGCF 
106 to I-CSCF 111 of the home network 113 of B 116 with +358- 
40-1223344. 

10 6a. The I-CSCF 111 performs a Location request to the HSS 112 
with the identifier E.164. The HSS 112 returns an identifier, 
e.g. the FQDN, of S-CSCF 114 where the B-subscriber is 
registered. 

7a. The I-CSCF 111 sends the message or session setup 
15 request, e.g. INVITE request, to S-CSCF 114. 

8a. The S-CSCF 114 may send the message or session setup 
request directly to the P-CSCF 115. 

9a. The P-CSCF 115 sends the message or session setup request 
to the B terminal 116. 

20 

5b. Because the message/messageset/session is not an IMS 
message/messageset/session according to the checked 
requirements it is sufficient to route it through non-IMS 
network (steps 5b or 5c) . As an alternative, the BGCF 106 
25 sends the message or session initiation request (e.g. INVITE) 
further to BGCF 110. 

6b. BGCF 110 forwards the message or session setup request to 
the MGCF 117 which connects the message or session setup 
request to the non-IMS e.g. CS network 118 (step 7b). 

30 

5c. As a further alternative, the BGCF 106 sends the message 
or session initiation request (e.g. INVITE) further to MGCF 
107. 

6c. MGCF 107 forwards the message or session setup request to 
35 the non-IMS e.g. CS network 118. 
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Advantages of this embodiment of the invention are: 
a) Efficient routing- The message and/or messageset and/or 
session is routed according to the proper requirements. 
5 b) No breakout to non-IMS e.g. CS domain if not needed, 
c) Reduced signaling. 

An idea of this embodiment of the invention is to route the 
message and/or messageset and/or session from BGCF to I-CSCF 
10 in another network if media and/or QoS and/or other 

requirements cannot be fulfilled in routing via non-IMS e.g. 
CS network. Otherwise the message/messageset/session e.g. 
call is routed to BGCF in another network or to MGCF in the 
own network. 

15 

In the previous embodiments of Fig. 3 and Fig. 13 and in the 
embodiments of Fig. 14 and Fig. 15 explained below, the 
decision of whether a certain received E.164 number is an IMS 
identity or not (e.g. in case the ENUM-DNS does not give any 

20 answer at the originating S-CSCF) , can be made at a network 
element or network function, preferably a control function 
such as S-CSCF or BGCF, based on the media and/or QoS (i.e. 
Quality of Service) requirements, and/or other message or 
session specific or general requirements. From the 

25 requirements it is deduced whether the message and/or 

messageset and/or session should be routed via IMS network or 
whether the routing via non-IMS e.g. CS network is 
sufficient. In the first case no breakout to non-IMS e.g. CS 
domain is done, i.e. the message and/or messageset and/or 

30 session is routed to I-CSCF of the target network. In the 
second case the message and/or messageset and/or session is 
routed to a BGCF of the target network or to a MGCF of the 
own network. 

35 These embodiments of the invention therefore provide means to 
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avoid routing IMS messages and/or messagesets and/or sessions 
through non-IMS e.g. CS network only because the originating 
S-CSCF does not get any answer from the local ENUM-DNS. If no 
means were used there would be the following consequences: 
5 Either the same number range cannot be used for both IMS and 
non-IMS e.g. CS subscribers, or if it is used there is no way 
to route an IMS message and/or messageset and/or session with 
E.164 to a bare IMS subscriber i.e. to the subscriber who has 
no non-IMS e.g. CS subscription (because ENUM-DNS does not 

10 give any answer, i.e. NAPTR RR, for the E.164). In the latter 
case if the subscriber has dual subscription (i.e. both IMS 
and non-IMS e.g. CS) and a dual terminal, those IMS messages 
and/or messagesets and/or sessions can be routed through non- 
IMS e.g. CS network where the media and/or QoS and/or other 

15 requirements can be fulfilled with the capabilities offered 
by the non-IMS e.g. CS network. If the requirements are more 
than the non-IMS e.g. CS network can offer, the message 
and/or messageset and/or session is released. Even if the 
message and/or messageset and/or session could be routed via 

20 non-IMS e.g. CS network it is in vain if the subscriber has 
only IMS subscription. 

Fig. 14 shows an embodiment providing such enhanced routing 
based on media and/or QoS and/or other requirements. The 
25 embodiment of Fig. 14 is in accordance with the above 

structure and functioning, and illustrates a flow according 
to both scenarios: 1) routing from S-CSCF to the target 
network; 2) routing from BGCF to the target network. Fig. 14 
also shows the functionality in S-CSCF and BGCF. 

30 

Assumptions in the Fig. 14 embodiment are that another ENUM- 
DNS database is utilized to help routing in the new 
functionality of S-CSCF or BGCF. Other means could as well be 
used instead of ENUM-DNS. 
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The upper block of Fig- 14 illustrates usual S-CSCF 
functionality. 

Upon start of the routine, step SI makes a ENUM-DNS query to 
5 the local ENUM-DNS database using the received identifier of 
the called party terminal, i.e. the E.164 number. The local 
ENUM-DNS database contains NAPTR RRs for the own IMS 
subscribers and possibly for the IMS subscribers of the 
trusted operators. 

10 

In step S2, it is checked whether or not the response 
contains at least one NAPTR RR. When the check result of step 
S2 indicates that the response contains at least one NAPTR 
RR, a step S3 is executed for translating the identifier of 
15 the called party terminal, i.e. the E.164 number to routable 
IMS identity e.g. SIP URI. In a subsequent step S4, the 
message and/or messageset and/or session is routed to I-CSCF 
of the target network. Thereupon, the function of the S-CSCF 
ends, step S5. 

20 

The block in the middle of Fig. 14 illustrates new 
functionality in S-CSCF or BGCF, and will be described below. 

When the check result of step S2 indicates that the response 
25 of the database in step SI does not contain at least one 

NAPTR RR, a step S6 is executed for checking media and/or QoS 
and/or other requirements of the message and/or messageset 
and/or session from the received message or session set up 
request . 

30 

In step S7, the result of the check of the media and/or QoS 
and/or other requirements of the requested message or 
messageset or session is compared to the media, QoS and other 
capabilities which can be provided by the selectable 
35 networks, e.g. CS network, non-IMS network, IMS network. 
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The selection of a network is performed in accordance with 
appropriate selection criteria which may e.g. consider 
networks availability, networks load, cost criteria, maximum 
5 or minimum QoS provided, etc. 

When detecting at step S7 that only IMS is able to provide 
the requested media, QoS and other capabilities so that IMS 
routing is required, the routine proceeds to step S8 where a 
10 further ENUM-DNS query is conducted to another ENUM-DNS 
database containing NAPTR RRs for IMS operators. 

Otherwise, when the answer in Step S7 is no, the program 
proceeds to step S9, so as to route the message and/or 
15 messageset and/or session to BGCF if not yet in BGCF. From 
step S9, the program proceeds to step S15 where the usual 
functionality in BGCF is provided. Thereafter the routing 
program of Fig. 14 is ended, step S16. 

20 The lower block of Fig. 14 illustrates usual functionality in 
BGCF. 

Following step S8, a step S10 is carried out wherein it is 
checked whether the response received in step S8 contains at 
25 least one NAPTR RR. 

If the answer to step S10 is yes, the routine proceeds to 
step S12 in order to translate the E.164 number to IMS 
routing address. Following step S12, step S13 is carried out 
30 where the message and/or messageset and/or session is routed 
with the IMS routing address to I-CSCF of the target network. 
Thereafter, the routing routine ends, step S14. 

If the answer received in step S10 is no, the routine 
35 proceeds to step Sll in order to route the message and/or 
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messageset and/or session to BGCF if not yet in BGCF. Then 
step S15 follows in the same manner as the response to step 
S9. 

5 An alternative in Sll is to release the message and/or 

messageset and/or session because according to the checked 
requirements the message and/or messageset and/or session 
cannot be routed through non-IMS e.g. CS network. This 
alternative is described in Fig. 1 and explained under the 
10 solution SI) "Release the message and/or messageset and/or 

session earlier, possibly already at the originating S-CSCF" . 

Advantages of the embodiments of the invention are: 

a) Operators do not need to reveal the content of their ENUM- 
DNS databases to other operators. 

b) Efficient routing. The message and/or messageset and/or 
session is routed according to the proper requirements. 

c) No breakout to non-IMS e.g. CS domain if not needed. 

d) The same number range can be used in IMS and non-IMS e.g. 
CS networks. 

e) Dual terminal is not necessary. 

In accordance with this embodiment, an idea is to route the 
message and/or messageset and/or session normally with E.164 
until S-CSCF or BGCF in the originating network. There the 
media and/or QoS and/or other requirements are checked, and 
according to these requirements the message and/or messageset 
and/or session is routed to I-CSCF in the target network if 
the requirements indicate that the message and/or messageset 
and/or session is an IMS message and/or messageset and/or 
session; or otherwise to MGCF in the own network or to BGCF 
in the target network. 

The invention gives also possibility to load sharing. If IP 
35 network is overloaded, message and/or messageset and/or 
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sessions where the media and/or QoS and/or other requirements 
can be fulfilled by the non-IMS e.g. CS network, can be 
routed via non-IMS e.g. CS network. And vice versa if non-IMS 
e.g. CS network is overloaded, IP network can be utilized 
instead. 

It may be easier to check the media and/or QoS and/or other 
requirements and route the message and/or messageset and/or 
session from BGCF than from S-CSCF to I-CSCF of the target 
network because BGCF is specialized to route messages and 
sessions further based on E.164 numbers. BGCF may drop itself 
out from the path after the "breakout" action. So the 
successive messages would pass directly from the originating 
S-CSCF to the terminating S-CSCF when the I-CSCF has also 
dropped itself out. 

On the other hand S-CSCF has the means to route the messages 
and sessions further to the target network by translating the 
E.164 to a routable IMS identity e.g. SIP URI with ENUM-DNS . 
So it may be easier to check the media and/or QoS and/or 
other requirements already in the S-CSCF. 

An idea of this embodiment of the invention is to route the 
message and/or messageset and/or session from the originating 
S-CSCF or BGCF to I-CSCF in the terminating network if the 
media and/or QoS and/or other requirements of the message 
and/or messageset and/or session indicate that the message 
and/or messageset and/or session is an IMS message and/or 
messageset and/or session. 

A further embodiment in accordance with the above described 
solution S3, "Route the message and/or messageset and/or 
session according to the media and/or QoS and/or other 
requirements", is shown in Fig. 15. This embodiment is quite 
similar to the embodiment of Fig. 3. Hence, the description 
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of Fig. 3 likewise applies to the embodiment according to 
Fig. 15 unless otherwise stated below. Further, the same 
numerals as in Fig. 3 are used to designate the same 
components of the Fig. 15 embodiment. 

5 

A difference between the embodiments according to Figs. 3 and 
15 is that it is the S-CSCF 4 in Fig. 3 which checks the media 
and/or QoS and/or other requirements for routing the message 
and/or messageset and/or session according to the media 
10 and/or QoS and/or other requirements. Contrary thereto, in 

the embodiment of Fig. 15, the BGCF 9 checks the media and/or 
QoS and/or other requirements for routing the message and/or 
messageset and/or session according to the media and/or QoS 
and/or other requirements. 

15 

In another embodiment, both the S-CSCF 4 and the BGCF 9 can 
check the media and/or QoS and/or other requirements for 
routing the message and/or messageset and/or session 
according to the media and/or QoS and/or other requirements. 

20 

According to the embodiment of Fig. 15, multimedia IMS 
messages and/or messageset and/or sessions are routed 
correctly to the target network. Non multimedia, e.g. voice, 
messages and/or messagesets and/or sessions are routed to the 
25 called party via non-IMS e.g. CS network. 

Checking media and/or QoS and/or other requirements is all 
that is needed. 

30 Fig. 15 illustrate s an example of an information flow 

according to solution S3. In this example, two local ENUM-DNS 
database 6, 7 are provided- The local ENUM-DNS database 6 
preferably is a ENUM-DNS database containing IMS E.164 
identities of subscribers to which the network 5 is the home 

35 network. The database 6 may also correspond to the local 
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ENUM-DNS database 6 of Fig. 2, and may include the same or 
essentially the same content as the latter. 

The local ENUM-DNS database 6 may include also IMS E.164 
5 identities of the trusted operators. This part of the 

database may contain delegations to appropriate ENUM-DNS 
databases of respective operators following standard DNS 
principles. The database 7 includes an ENUM-DNS database 
containing information to find FQDN (FQDN = Fully Qualified 

10 Domain Name) of foreign I-CSCFs (i.e. I-CSCFs of other 

operators/networks). Instead of the database 6 other means 
may be used to help translating E.164 to corresponding 
routing address. Instead of the database 7 other means, e.g. 
routing tables, may be used to find address of foreign I- 

15 CSCFs. 

A HSS query (HSS = Home Subscriber Server), step 7, is also 
involved, as shown in Fig. 15. 

20 The embodiment of Fig. 15 includes the following steps. 

1) A message or session request message, e.g. SIP INVITE 
message, indicating the E.164 number of a called party, e.g. 
+358-50-22112233 which may be E.164 of Radiolinja's IMS 

25 subscriber, is sent from user equipment A to P-CSCF 2 of the 
visited network 3 visited by (e.g. roaming) subscriber A 1. 

2) The P-CSCF 2 of the visited network 3 sends a message or 
session request message, e.g. INVITE message, to the S-CSCF 4 

30 of A subscriber's home network 5, indicating the E.164 number 
of the called party, +358-50-22112233. 

3) The S-CSCF 4 of the home network 5 performs a local IMS 
ENUM-DNS query to the local ENUM-DNS database 6, indicating 

35 the E.164 number. When assuming that the local ENUM-DNS 

52 



WO 2004/008786 



F CT/IB2002/002782 



database 6 does not contain the called IMS subscribers , there 
will be, in this case, an "unknown domain", "not found" or 
alike response or no response at all from ENUM-DNS database 
6. 

5 

3 1 ) Because no NAPTR resource records were received from 
ENUM-DNS database 6, the IMS identity is considered non-IMS 
identity. 

10 4) The message or session setup request is then routed to 
BGCF 9 of the home network 5 of subscriber A. 

S4 1 ) The BGCF 9 checks the media requirements and/or QoS 
requirements and/or other requirements of the 
15 message/messageset/session by checking the information 

contained in the request received from P-CSCF 2/S-CSCF4 in 
order to decide whether the message/messageset/session can be 
routed through non-IMS (e.g. CS) network or whether it should 
be routed via IMS network. 

20 

5) When the message/messageset/session has to be routed via 
IMS network, the E.164 is regarded as an IMS identity. In 
order to route to the I-CSCF 12 the address of the I-CSCF 12 
is needed. 

25 

The BGCF 9 of the home network 5 therefore performs a local 
IMS ENUM-DNS query to the local ENUM-DNS database 7, 
indicating the E.164 number. Routing address to I-CSCF 12 is 
built with the help of NAPTR RRs received from the local 
30 ENUM-DNS database 7. 

6) When the check of step 4') indicates that the 
message/messageset/session cannot be routed through non-IMS 
network, the message/messageset/session is then routed 

35 further from BGCF 9 to the I-CSCF 12 in the home network 10 
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of subscriber B. 

7) The I-CSCF 12 performs a HSS 13 query using the E.164 
number. The HSS 13 returns the address of S-CSCF 14 of the 

5 home network 10 of subscriber B. 

8) The message/messageset /session is then routed to the 
indicated S-CSCF 14, 

10 9) A message/session request, e.g. INVITE message is sent 
from S-CSCF 14 to P-CSCF 15 of network 10 of B, indicating 
IMS identity of B. 

10) The P-CSCF 15 routes the message/messageset/ session to 
15 subscriber 17 so that the message/messageset/ session is 
transmitted/established from A to B. 

When the check performed in step 4') of Fig. 15 should 
indicate that the message/messageset/session need not to be 
20 routed via IMS network, the message/messageset/session may be 
routed via non-IMS network i.e. from BGCF 9 via MGCF 8, and 
CS network 18 , to entity 17. 

Generally, for all above described embodiments, it is to note 
25 that BGCF is a functionality that may be implemented as an 
own network element or included in another functionality 
and/or another network element e.g. S-CSCF. 

Likewise, DGCF is a functionality that may be implemented as 
30 an own network element or included in another functionality 
and/or another network element e.g. I-CSCF and/or BGCF. 

Further, QoS and/or media requirements are only examples of 
the checks that may be needed to decide what is the correct 
35 routing. Instead of or in addition to them other checks may 
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be needed and/or done. 

In the above text, the notation "message/session" means 
"message and/or session". In the above text, the notation 
5 "message/messageset/session" means "message and/or messageset 
and/or session". 

The invention can be applied - in addition to IMS networks - 
also to other networks e.g. WLAN; and other IP based 

10 networks; or in general to whatever two networks that use a 

third network, which cannot fulfill the same media and/or QoS 
and/or other requirements as the first and the second 
network, to carry part of the traffic from the first network 
to the second network via the third network. The part of the 

15 traffic may be traffic addressed with whatever numbering 
system e.g. E.164. The idea of ENUM can be applied — in 
addition to E.164 — also to other numbering systems. 

In this invention the ENUM can always be replaced with other 
20 means e.g. with routing tables, databases, tables, lists or 
alike independently whether it is used at the originating S- 
CSCF to transform E.164 to an IMS address or elsewhere to get 
a routing address to the next network element. 

25 SIP URL and SIP URI are used interchangeable i.e. they both 
mean a valid address that can be used in SIP. Thus, a valid 
IMS routing address may be e.g. SIP URI or SIP URL. As an 
example, routing of SIP signalling within the IMS may use SIP 
URLs. According to the current standard draft E.164 format 

30 public user identities should not be used for routing within 
the IMS, and session requests based upon E.164 format public 
user identities will require conversion into SIP URL format 
for internal IMS usage. 

35 ENUM- DNS and ENUM/ DNS and ENUM+DNS are used interchangeable. 
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CS, GSM and PSTN networks are some examples of non-IMS 
networks . 

5 The invention is not limited to use only ENUM-DNS in order to 
answer the question (Ql) , whether the target identifier i.e. 
the E.164 number is a valid IMS identity. In addition to 
ENUM-DNS or instead of ENUM-DNS also other means e.g. 
table (s), list(s), file(s), database (s) or alike may be used 
10 in the invention. 

The invention is not limited to use only ENUM-DNS in order to 
route messages and/or messagesets and/or sessions such as 
E.164 messages and/or messagesets and/or sessions. In 
15 addition to ENUM-DNS or instead of ENUM-DNS also other means 
e.g. routing table (s), routing list(s), routing filets), 
routing database (s) or alike may be used in the invention. 

In accordance with a main idea of some of the embodiments of 
the invention, a single method (i.e. ENUM-DNS) is used for 
all E.164 routing by combining the existing ENUM-DNS 
database, e.g. in TS 23.228, with a new ENUM-DNS database to 
create a complete routing method for E.164. And to reuse the 
existing ENUM-DNS database, e.g. in TS 23.228, to create a 
new routing feature: routing from terminating BGCF to I-CSCF. 

Further, an additional or alternative idea of the invention 
implemented in some of the embodiments is to route E.164 and 
logical names separately and without any help of ENUM-DNS 
30 databases and allow routing between I-CSCF and BGCF (in the 
same network) to both directions. 

According to a main idea of some of the embodiments of the 
invention, only one contact point type is used in the network 
35 and thus the need for separation of the routing in the 
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originating network into two groups is eliminated: IMS 
addresses (to I-CSCF) and non IMS addresses (to BGCF) . 
Therefore ENUM is not needed, neither routing database, e.g. 
TRIP, for routing between BGCFs in different networks. 

5 

According to some of the embodiments of the invention, a 
message and/or messageset and/or session is routed from the 
own S-CSCF or BGCF to I-CSCF in another network if media 
and/or QoS and/or other requirements cannot be fullfilled in 
10 routing via non-IMS e.g. CS. Otherwise the message and/or 

messageset and/or session e.g. call is routed from own BGCF 
to BGCF in another network or to MGCF in the own network. 

A further alternative or additional teaching of the invention 
is to route a message and/or messageset and/or session from 
the originating S-CSCF or BGCF to I-CSCF in the terminating 
network if the media and/or QoS and/or other requirements of 
the message and/or messageset and/or session tell that it is 
an IMS session. 

In some of the above embodiments, a BGCF is used as a contact 
point (e.g. depending on the routing to BGCF or I-CSCF). 
Instead of a BGCF, any appropriate network element or control 
function can be used as such contact point. 

Further, presently CSCF is usually understood as Call State 
Control Function. CSCF may also mean Call session Control 
Function in some or all cases, e.g. in a future naming. 

In the above description, one or two or three databases, e.g. 
ENUM- DNS databases or provided. It is to be understood that 
these first, second and/or third databases may be located in 
the same entity, or in different entities. These terms are 
mainly used to describe the type of information the databases 
35 contain. 
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The ENUM databases of the first network can be combined in 
such a way that if the first query to the first database does 
not yield any NAPTR resource records, then the second ENUM 
5 database will automatically be queried and the routing 

address to a contact point to the second network is received. 
So the ENUM database query can be transparent even to the 
network element/functionality level (e.g. S-CSCF or BGCF 
level) . This way only one query needs to be done by the 
10 network element/functionality to get the routing address to a 
contact point to the second network. 

The invention is not limited to use only E.164 numbering 
schemes, also messages and/or messagesets and/or sessions 
15 using other numbering schemes e.g. E.212 can be routed with 
this invention. 

The invention is not limited to use only access networks of 
IMS but also other access networks can be used. 

20 

The invention is not limited to use only terminals and/or 
user equipments of IMS but also other kind of terminals 
and/or user equipments can be used. 

25 List of used abbreviations 

BGCF Breakout Gateway Control Function 
CS Circuit Switched 

CSCF Call State Control Function, or Call Session Control 

Function 
30 DNS Domain Name System 

ENUM is defined in RFC 2916 "E.164 number and DNS" 

ENUM- DNS ENUM on DNS 

FQDN Fully Qualified Domain Name 

GMSC Gateway MSC 
35 GSM Global System for Mobile Communications 
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HSS Home Subscriber Server 

I-CSCF Interrogating Call State Control Function 
IM IP Multimedia 

IMS IP Multimedia Core Network Subsystem (see 3GPP TS 
5 23.228) 

IP Internet Protocol 
LN Logical Name 

MGCF Media Gateway Control Function 

NAPTR Naming Authority Pointer (see RFC 2915) , RR of DNS 

10 NE Network Element 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RR Resource Record of DNS 

S-CSCF Serving Call State Control Function 
15 SIP Session Initiation Protocol (see RFC 3261, old: RFC 
2543) 

SIP URI see RFC 3261 (SIP URL in RFC 2543) 
SIPS URI secure SIP URI, see RFC 3261 

SRV A DNS RR for specifying the location of services (DNS 
20 SRV) (RFC 2782) 

TRIP A Framework for Telephony Routing over IP (RFC 2871) 
URI Uniform Resource Identifier 
URL Uniform Resource Locator 

25 Although preferred embodiments have been described above, the 
invention is not limited thereto and may also be implemented 
in other ways, e.g. by combining, in any arbitrary fashion, 
one or more features of one or more embodiments with one or 
more features of other embodiments . 



30 
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CLAIMS 

5 

1. Method for routing a message or messageset or session 
setup request from a first network to a second network, the 
message or messageset or session set up request comprising a 
10 first type of address, comprising steps of: 

checking if the first type of address is transformable 
to a second type of address using a first database in the 
first network, 

deriving the address of a contact point of the second 
15 network in the first network, 

wherein the message or messageset or session setup 
request is forwarded to the second network using the contact 
point of the second network. 

20 2. A method of claim 1, wherein the deriving step is 

done using a second database. 

3. A method for routing a message or messageset or 
session setup request from a first network to a second 
25 network, the message or messageset or session set up request 
comprising a first type of address, comprising steps of: 

checking if the first type of address is transformable 
to a second type of address using a first database in the 
first network, 

30 checking requirements of message or set of messages or 

session from the message or message set or session set up 
request, and 

deciding based on the result of the requirements 
checking step, on the routing of the message or messageset or 
35 session setup request. 
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4. A method according to claim 3, comprising a step of 
deriving the address of a contact point of the second network 
in the first network, 

5 wherein the message or messageset or session setup 

request is forwarded to the second network using the contact 
point of the second network. 

5. A method according to claim 4, wherein the deriving 
10 step is done using a second database. 

6. A method according to claim 3, where the session or 
messageset or session set up request is released based on the 
result of the requirement check in the first network. 

7. A method according to any of the preceding claims, 
wherein the message or messageset or session set up request 
is forwarded to the contact point, the method further 
comprising the steps of: 

deriving the routing address of the session set up 
request or message or messageset in the second network using 
a third databases- 
routing the session set up request or message or 
messageset from the contact point to a further network entity 
based on the derived address. 

8. Method according to claims 3 or 7, wherein the 
checked requirements include media requirements of the 
message or set of messages or requested session. 

9. Method according to claim 3 or 7, wherein the checked 
requirements include QoS requirements of the message or set 
of messages or requested session. 

10. Method according to any one of the preceding claims, 
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wherein a Serving Call State Control Function (S-CSCF) 
performs the requirement checking step. 

11. Method according to any one of the preceding method 
5 claims, wherein a Breakout Gateway Control Function (BGCF) 

performs the requirement checking step. 

12. Method according to any one of the preceding claims, 
wherein said first or second network or another network 
involved in routing the message or session setup request, 
includes a Call State Control Function (CSCF) and a Breakout 
Gateway Control Function (BGCF), the Call State Control 
Function (CSCF) and the Breakout Gateway Control Function 
(BGCF) being adapted to utilize at least partly different DNS 
databases for translating an identifier of an equipment 
indicated in the message or session setup request, into a 
routing information. 

13. Method according to any one of the preceding claims, 
20 wherein a Control Function, preferably a Dividing Gateway 

Control Function (DGCF), performs the requirement checking 
step and takes care of routing incoming traffic from IP 
multimedia networks. 

14. Method according to any one of the preceding claims, 
wherein the second network includes a breakout element, 
preferably a Breakout Gateway Control Function (BGCF) , and an 
interrogating element, preferably an Interrogating Call State 
Control Function (I-CSCF), and an additional path is provided 
from the breakout element to the interrogating element for 
routing a message or messageset or session setup request. 

15. Method according to claim 14, wherein, when an 
identifier of the second network included in the message or 

35 messageset or session setup request indicates a valid IMS 
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15 



identity, the message or messageset or session setup request 
is routed from the breakout element to the interrogating 
element, otherwise the message or messageset or session setup 
request is routed to a media gateway element, preferably a 
5 Media Gateway Control Function (MGCF) . 

16. Method according to claim 15, wherein, when the 
message or messageset or session setup request is routed from 
the breakout element to the interrogating element, the 

10 breakout element is adapted to drop itself out so that the 
routing is a normal IMS session. 

17. A method according to any of the preceding claims 
wherein the contact point is an I-CSCF, BGCF or DGCF. 

18. A method according to any of the preceding claims 
wherein the first database is an ENUM DNS database and 
comprises IMS E.164 identities of the subscribers who have 
the first network as a home network. 

19. Method according to claim 3, wherein the first 
database contains E.164 identities of the trusted operators. 

20. Method according to any of the preceding claims 
25 wherein the first type of address is an E.164 identity and 

the second type of address is a routable IMS identity. 

21. Method according to any one of the preceding claims 
wherein the routable IMS identity is a SIP URI or SIPS URI . 

30 

22. A method for routing a message, messageset or a 
session set up request in a communication network from a 
first network of a first type to a second network of a second 
type, comprising the steps of: 

35 initiating a message, messageset or a session setup 
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request in the first network 

routing the message, messageset or session set up 
request from the first network to a media gateway element of 
the second network and 
5 routing the message, messageset or session set up 

request from the media gateway element to a breakout element 
in the second network, 

wherein the second network includes a breakout element, 
preferably a Breakout Gateway Control Function (BGCF) , -and a 
10 media gateway element, preferably a Media Gateway Control 
Function (MGCF) . 

23. System for routing a message or messageset or 
session setup request from a first network to a second 
network, the message or messageset or session set up request 
comprising a first type of address, comprising: 

checking means for checking if the first type of address 
is transformable to a second type of address using a first 
database in the first network, 

deriving means for deriving the address of a contact 
point of the second network in the first network, 

wherein the system is adapted to forward the message or 
messageset or session setup request to the second network 
using the contact point of the second network. 

24. A system of claim 23, wherein the deriving means is 
adapted to access a second database. 

25* A system for routing a message or messageset or 
30 session setup request from a first network to a second 

network, the message or messageset or session set up request 
comprising a first type of address, comprising: 

checking means for checking if the first type of address 
is transformable to a second type of address using a first 
35 database in the first network, 
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further checking means for checking requirements of 
message or set of messages or session from the message or or 
message set or session set up request, and 

deciding means for deciding, based on the result of the 
5 further checking means, on the routing of the message or 
messageset or session setup request. 

26. A system according to claim 25, comprising means for 
deriving the address of a contact point of the second network 
10 in the first network, 

wherein the system is adapted to forward the message or 
messageset or session setup request to the second network 
using the contact point of the second network. 

15 27- A system according to claim 26, wherein the deriving 

means is adapted to access a second database. 

28. A system according to any of the preceding system 
claims, wherein the message or messageset or session set up - 
20 request is forwarded to the contact point, the system further 
comprising: 

means for deriving the routing address of the session 
set up request or message or messageset in the second network 
using a third database; 
25 means for routing the session set up request or message 

or messageset from the contact point to a further network 
entity based on the derived address. 

29- A system according to claims 25 or 28, wherein the 
30 checked requirements include media requirements of the 
message or set of messages or requested session. 

30. A system according to claim 25 or 26, wherein the 
checked requirements include QoS requirements of the message 
35 or set of messages or requested session. 
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31. A system according to any one of the preceding 
system claims, comprising a serving control function, 
preferably a Serving Call State Control Function (S-CSCF) , 

5 for performing the requirement check. 

32. A system according to any one of the preceding 
system claims, comprisisng a Breakout Gateway Control 
Function (BGCF) for performing the requirement checking step. 



33. A system according to any one of the preceding 
system claims, wherein said first or second network or 
another network involved in routing the message or session 
setup request, includes a Call State Control Function (CSCF) 

15 and a Breakout Gateway Control Function (BGCF), the Call 
State Control Function (CSCF) and the Breakout Gateway 
Control Function (BGCF) being adapted to utilize at least 
partly different DNS databases for translating an identifier 
of an equipment indicated in the message or session setup 

20 request, into a routing information. 

34. A system according to any one of the preceding 
system claims, wherein a Control Function, preferably a 
Dividing Gateway Control Function (DGCF), is provided for 

25 performing the requirement check and for taking care of 
routing incoming traffic from IP multimedia networks. 

35. A system according to any one of the preceding 
system claims, wherein the second network includes a breakout 

30 element, preferably a Breakout Gateway Control Function 
(BGCF), and an interrogating element, preferably an 
Interrogating Call State Control Function (I-CSCF), and an 
additional path is provided from the breakout element to the 
interrogating element for routing a message or messageset or 

35 session setup request. 
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36. A system according to claim 35, wherein, when an 
identifier of the second network included in the message or 
messageset or session setup request indicates a valid IMS 
identity, the message or messageset or session setup request 
is routed from the breakout element to the interrogating 
element, otherwise the message or messageset or session setup 
request is routed to a media gateway element, preferably a 
Media Gateway Control Function (MGCF) . 



37. A system according to claim 36, wherein, when the 
message or messageset or session setup request is routed from 
the breakout element to the interrogating element, the 
breakout element is adapted to drop itself out so that the 

15 routing is a normal IMS session. 

38. A system according to any of the preceding system 
claims, wherein the contact point is an I-CSCF, BGCF or DGCF. 

20 39. A system according to any of the preceding system 

claims wherein the first database is an ENUM-DNS database and 
comprises IMS E.164 identities of the subscribers who have 
the first network as a home network. 

25 40. A system according to claim 25, wherein the first 

database contains E.164 identities of the trusted operators. 

41. A system according to any of the preceding system 
claims wherein the first type of address is an E.164 identity 

30 and the second type of address is a routable IMS identity. 

42. A system according to any one of the preceding 
system claims wherein the routable IMS identity is a SIP URI 
or SIPS URI. 
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43. A system for routing a message, messageset or a 
session set up request in a communication network from a 
first network of a first type to a second network of a second 
type, comprising: 

means for initiating a message, messageset or a session 
setup request in the first network, 

means for routing the message, messageset or session set 
up request from the first network to a media gateway element 
of the second network and 

means for routing the message, messageset or session set 
up request from the media gateway element to a breakout 
element in the second network, 

wherein the second network includes a breakout element, 
preferably a Breakout Gateway Control Function (BGCF) , and a 
media gateway element, preferably a Media Gateway Control 
Function (MGCF) . 
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E.164 routing within IMS 




ROUTING with logical name: 
1 

2 

S-CSCF find out that it is not E.164 but a logical name and gets FQON of l-CSCF from the logical name. 

3a 

6 

7 

8 

9 

ROUTING with IMS E.164: 
1 

2 

S-CSCF find out that it is E.164 and routes the call to a BGCF in the own network. 

3b 

4 

BGCF in the target network finds out that it is IMS E.164 and routes the call to l-CSCF. 

5a 

6 

7 

8 

9 



ROUTING with non IMS E.164: 
1 

2 

S-CSCF find out that it is E.164 and routes the can to a BGCF in the own network. 

3b 
4 

BGCF in the target network finds out that it is not IMS E.164 and routes the call to one of the own MGCFs. 
5b 
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CALLS FROM PSTN 




NETWORK B 



50 



ROUTING with IMS E.164 in the own 

1 

2 

BGCF find out that J-CSCF takes care of the number. 

3a 

4 

5 

6 

7 

ROUTING with IMS E.164 to another 

1 

2 

BGCF find out that BGCF in another network takes care of the number. 
3b 

BGCF find out that 1-CSCF takes care of the number. 

8a 

9 

10 

11 

12 

ROUTING with non IMS E.164 to another 
1 

2 

BGCF find out that BGCF in another network takes care of the number. 
3b 

BGCF find out the MGCF that takes care of the number. 
8b 
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New functionality in S-CSC F or BGCF 
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Check the media and/or QoS and/or 
other requirements of the message/ 
messageset/session 




-NO- 



Route the message/ 
messagesel/session to 
BGCF if not yet in BGCF. 



S9 



Make a ENUM-DNS query to 

another ENUM-DNS 
database containing NAPTR 
RRs for IMS operators. 




Translate the E. 164 to IMS 
routing address 



YES 



Route the message/ 
messageset/session to I- 
CSCF of the target network. 



NO 



END 



Route the message/ 
messageset/session to 
BGCF if not yet in BGCF. 
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Usual BGCF functionality 
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Usual functionality in BGCF 
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